IDA 


INSTITUTE  FOR  DEFENSE  ANALYSES 


A  GH-Based  Ontology  to  Support 
Applications  for  Automating 
Decision  Support 


Francisco  L.  Loaiza,  Task  Leader 
Steven  R  Wartik 


March  2005 

Approved  for  public  release; 
unlimited  distribution. 

IDA  Paper  P-3934 
Log:  H  04-001665 


This  work  was  conducted  under  contracts  DASW01  98  C  0067/ 
DASW01  02  C  0012,  Task  BC-1-2245,  for  the  Assistant  Secretary  of 
Defense  (CIO/G-6).  The  publication  of  this  IDA  document  does  not  indicate 
endorsement  by  the  Department  of  Defense,  nor  should  the  contents  be 
construed  as  reflecting  the  official  position  of  that  Agency. 

©  2004,  2005  Institute  for  Defense  Analyses,  4850  Mark  Center  Drive, 
Alexandria,  Virginia  22311-1882  •  (703)845-2000. 

This  material  may  be  reproduced  by  or  for  the  U.S.  Government  pursuant 
to  the  copyright  license  under  the  clause  at  DFARS  252.227-7013 
(NOV  95). 


INSTITUTE  FOR  DEFENSE  ANALYSES 


IDA  Paper  P-3934 


A  GH-Based  Ontology  to  Support 
Applications  for  Automating 
Decision  Support 


Francisco  L.  Loaiza,  Task  Leader 
Steven  R  Wartik 


Preface 


This  document  was  prepared  under  the  Task  Order  BC-1-1508.  It  was  performed  in  re¬ 
sponse  to  a  task  objective  to  formulate  sustaining  base  data  exchange  requirements  using 
existing  information  exchange  standards  specifications. 

We  wish  to  thank  Mr.  Bruce  Haberkamp  (Army  CIO/G6)  for  his  support  of  this  project. 

The  following  Institute  for  Defense  Analyses  (IDA)  research  staff  members  were  review¬ 
ers  of  this  document:  Dr.  L  Roger  Mason,  Jr.,  Dr.  Reginald  N.  Meeson,  Dr.  Eugene  Si- 
maitis,  and  Mr.  David  Wheeler. 


V 


Contents 


EXECUTIVE  SUMMARY . ES-1 

1.  INTRODUCTION . 1 

1.1  Background . 1 

1 .2  Purpose  of  the  Document . 5 

1 .3  Intended  Audience . 6 

1 .4  Organization  of  this  Document . 6 

2.  PROJECT  OVERVIEW . 7 

3.  A  C2  ONTOLOGY . 9 

3 . 1  Background  on  the  Generic  Hub . 9 

3.2  A  GH  Ontology . 13 

3.2.1  Business  Rules . 13 

3.2.2  The  Knowledge  Model . 14 

3.2.3  Representing  the  GH  Using  Frames . 15 

3.2.4  Modeling  Type  Equivalence . 17 

3.2.5  Modeling  Measurable  Things . 18 

3.2.6  Modeling  Order . 21 

3.3  Creating  a  C2  Ontology . 21 

3.4  Implementing  the  C2  Ontology . 24 

3.4.1  Abstract  Classes . 27 

3.4.2  Inverse  Slots . 29 

3.4.3  Metaclasses . 30 

3.5  Status  of  the  Implementation . 31 

4.  USING  THE  ONTOLOGY  FOR  DECISION  SUPPORT . 33 

4 . 1  Operational  Architecture . 33 

4.2  System  Architecture . 33 

4.3  A  Prototype  Implementation . 37 

4.3.1  Agent  Technologies . 38 

4.3.2  Database  Technologies . 39 

4.3.3  XML  Technologies . 40 

4.3.4  Prototype  Components . 40 

4.3.5  The  Data  Set . 42 

4.3.6  The  Decision  Support  Application . 43 

4.3.7  Implementing  Inferencing . 46 

4.3.8  Metrics . 47 

5.  CONCLUSIONS  AND  DIRECTIONS . 49 


v 


5.1  The  GH  Ontology . 49 

5.2  The  C2  Ontology . 50 

5.3  Use  of  Ontologies . 51 

5 .4  The  Prototype . 51 

REFERENCES . REF-1 

ABBREIVATIONS  AND  ACRONYMS . ACROS-1 

ANNEX  A:  Design  of  the  Ontologies . A-l 

ANNEX  B:  Design  of  a  Net-Centric  System  Using  the  GH  Ontology . B-l 

ANNEX  C:  Friendly  Organization  Implementation . C-2 

ANNEX  D:  GHS  Ontology  Implementation . D-l 


List  of  Figures 


Fig.  1  Data  Sharing  Today . 1 

Fig.  2  Net-Centric  System  Execution  Concept . 3 

Fig.  3  Entity-Relationship  Model  of  Selected  GH5  Elements . 10 

Fig.  4  GH5  Location  Entity  Hierarchy . 11 

Fig.  5  GH5  Reporting  Data  Entities  and  Attributes . 12 

Fig.  6  Translation  from  ER  Model  to  Frame  Model . 16 

Fig.  7  An  Illustration  of  the  Type  of  Hierarchy . 18 

Fig.  8  Numeric  Expression  Class  Hierarchy . 20 

Fig.  9  Unit  of  Measurement  Mapping  Hierarchy . 20 

Fig.  10  Scenario  for  C2  Ontology  Use . 23 

Fig.  11  Protege-2000 . 28 

Fig.  12  Location  Hierarchy  in  Protege-2000 . 29 

Fig.  13  Metaclasses  in  the  GH  Ontology . 31 

Fig.  14  High-Level  System  Architecture . 34 

Fig.  15  Agent  System  Architecture . 36 

Fig.  16  Agent  System  Sequnce  Diagram . 38 

Fig.  17  Prototype  System  Components . 41 

Fig.  18  Hostile  Organization  User  Interface . 42 

Fig.  19  Migration  of  ORGANISATION-TYPE  from  GH4  to  GH5 . 43 

Fig.  20  The  Decision  Support  Application  User  Interface . 45 

Fig.  21  Example  Courses  of  Action . 46 

Fig.  22  Example  Justification  for  Course  of  Action . 46 


vii 


Executive  Summary 


Background 

The  United  States  Department  of  Defense  is  pursuing  new  approaches  to  manage  infor¬ 
mation  that  will  accelerate  decision  making  and  improve  joint  war  fighting.  The  DoD’s 
Chief  Infonnation  Officer  (CIO)  advocates  building  a  foundation  for  net-centric  opera¬ 
tions.  This  foundation  will  ultimately  entail  broad  transfonnation.  High-bandwidth  net¬ 
work  hardware  and  powerful  data  fusion  tools  will  be  required  to  take  advantage  of  net- 
centric  benefits.  No  less  important  will  be  new  operational  processes  used  by  decision 
makers  to  react  to  the  myriad  sources  that  will  make  data  available  to  them. 

In  a  memorandum  issued  in  May  2003,  the  DoD  CIO  established  an  aggressive  plan  for 
achieving  net-centricity.  This  memorandum  called  for  plans  to  be  in  place  by  the  end  of 
2003,  and  for  implementation  guides  to  be  published  during  2004.  Architecture  develop¬ 
ment  is  to  be  ongoing.  The  memorandum  envisioned  active  development  on  net-centric 
efforts  starting  at  least  as  early  as  2005.  Given  the  scope  of  information  extant  in  the 
DoD,  this  schedule  is  extraordinarily  bold. 

The  memorandum  that  lays  out  the  net-centric  data  strategy  establishes  seven  goals 
(Table  1),  and  defines  approaches  to  achieve  each  goal.  It  provides  an  assessment  of  the 
challenges  DoD  faces  in  providing  net-centricity.  These  challenges  are  accompanied  by 
mitigation  techniques.  It  is  not  yet  known  how  effective  the  techniques  will  prove,  but 
they  seem  likely  to,  at  a  minimum,  establish  an  environment  in  which  net-centricity  can 
exist. 

DoD  recognizes  that  net-centricity  has  hazards.  One  is  information  overload.  The  total 
information  awareness  available  to  any  application  on  the  Global  Information  Grid 
(GIG),  the  network  foundation  of  net-centricity,  comes  by  definition  from  the  huge 
amount  of  information  the  GIG  can  supply  -  perhaps  orders  of  magnitude  more  than 
some  decision  makers  currently  process.  Every  user  of  the  Google  search  engine  has  been 
confounded  by  several  hundred  thousand  web  pages  in  response  to  a  simple  query.  The 
chance  of  overlooking  information  may  be  of  little  consequence  for  the  average  web 


Table  1.  Net-Centric  Data  Goals 


Goal 

Description 

Visible 

Applications  and  users  can  discover  the  existence  of  data  assets. 

Accessible 

Applications  and  users  post  data  to  a  shared  space. 

Institutionalize 

DoD  processes  and  practices  incorporate  net-centric  approaches. 

Understandable 

Applications  and  users  can  comprehend  data  syntax,  structure,  and  semantics. 

Trusted 

Applications  and  users  can  access  the  pedigree,  security  level,  and  access  control  level  of 
each  data  asset. 

Interoperable 

System  interfaces,  sometimes  predefined  and  sometimes  unanticipated,  provide  many-to- 
many  exchanges  of  data. 

Responsive  to  User 
Needs 

User  perspectives  are  incorporated  into  data  approaches  via  continual  feedback. 
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search.  Within  a  combat  situation,  it  can  threaten  war  fighters’  lives.  DoD  applications 
must  be  prepared  to  deal  with  infonnation  overload. 

The  Data  Understandability  Goal 

One  goal  of  the  net-centric  data  strategy  is  enabling  data  to  be  understandable.  For  data  to 
be  shared,  applications  and  users  must  be  able  to  obtain  and  infer  data  syntax  and  seman¬ 
tics.  Relying  on  existing  data  standards  is  inadequate  because  these  standards  are  subject 
to  change.  Instead,  metadata  that  describes  data  must  be  available.  The  DoD  expects  each 
Community  of  Interest  (Col)  to  create  and  publish  metadata  as  part  of  the  Col’s  commit¬ 
ment  to  net-centricity. 

Data  syntax  and  semantics  are  to  be  explicated  through  ontologies.  In  this  study,  we  de¬ 
fine  an  ontology  as  a  fonnalized  specification  of  the  semantics  applicable  to  the  constitu¬ 
ents  of  our  universe  of  discourse.  An  ontology  formally  describes  the  meaning,  proper¬ 
ties,  and  interrelationships  of  said  constituents.  In  addition,  an  ontology  can  specify  perti¬ 
nent  inference  rules.  Because  of  the  latter,  an  ontology  can  help  applications  reason  about 
data.  Furthermore,  an  ontology  can  provide  an  intennediate  layer  that  insulates  applica¬ 
tions  from  the  specific  encoding  of  the  data. 

The  DoD  intends  to  provide  metrics  and  incentives  that  will  encourage  Cols  to  develop 
ontologies.  These  ontologies  will  be  published  in  a  central  registry  and  available  to  all 
Cols  through  the  GIG. 

Achieving  the  goal  of  enabling  data  to  be  understandable  may  be  key  to  handling  infor¬ 
mation  overload.  If  data  can  be  understood,  unnecessary  data  can  be  filtered  out,  or  at 
least  flagged  as  of  low  interest.  Google  prioritizes  data,  but  since  web  page  developers  do 
not  publish  a  detailed  ontology,  Google  relies  on  strategies  that  can  be  considered  primi¬ 
tive  relative  to  what  could  be  accomplished  within  DoD’s  vision.  That  Google’s  first  few 
pages  almost  invariably  contain  all  interesting  information  hints  at  what  a  sophisticated 
ontology  might  provide.  Of  course,  the  Google  user  still  has  to  examine  several  hits  to 
determine  if  a  link  is  truly  interesting.  DoD’s  vision  is  that  an  agent  will  be  able  to  under¬ 
take  this  role. 

The  above  arguments  are  conceptual.  Success  of  net-centricity  will  depend  on  whether 
Cols  can  develop  sufficiently  expressive  ontologies,  whether  real-world  applications  can 
infer  enough  from  them  to  prevent  information  overload,  and  whether  an  ontology’s 
value  exceeds  the  cost  of  defining,  maintaining,  and  using  it. 

An  Example  for  the  C2  Col 

IDA  has  undertaken  a  study  on  the  creation  of  a  Command  and  Control  (C2)  ontology  for 
a  net-centric  environment.  The  study  is,  therefore,  concerned  with  expressing  C2  con¬ 
cepts.  IDA  envisions  the  C2  ontology  to  be  a  fully  documented  specification  that  will  be¬ 
come  a  managed  resource  similar  to  the  Extensible  Markup  Language  (XML)  metadata 
currently  published  in  the  DoD  Metadata  Registry.  This  C2  ontology  will  help  applica¬ 
tions  and  users  understand  the  syntax  and  semantics  of  C2  data. 

The  ontology  is  an  exploration  of  the  kinds  of  metadata  that  could  be  published  in  the  C2 
domain.  It  is  also  intended  as  a  test  bed  to  study  the  degree  to  which  applications  can  fil- 
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ter  out  information  of  no  use  to  a  decision  maker  and  prioritize  the  rest.  Testing  this  fun¬ 
damental  issue  of  net-centricity  will  help  DoD  plot  the  course  of  net  centricity. 

IDA  is  testing  data  filtering  by  building  a  prototype  system  that  performs  decision  sup¬ 
port  in  a  simulated  battlefield  environment.  The  system  simulates  a  set  of  hostile  organi¬ 
zations  and  a  set  of  mutually  friendly  organizations.  The  friendly  organizations  collect 
and  share  intelligence.  Each  friendly  organization  has  a  decision  support  application  that 
uses  the  C2  ontology  to  analyze  the  data  it  receives,  and  to  present  the  following  to  a  war 
fighter: 

•  Threats  detected:  Inferences  regarding  threats  to  any  friendly  organization. 

•  Prioritized  courses  of  action:  The  application’s  analysis  of  reasonable  decisions  in 
response  to  threats,  measured  on  a  scale  of  zero  to  one. 

•  Rationale:  A  justification  of  the  priority  the  application  has  assigned  to  each 
course  of  action. 

In  this  context,  data  filtering  occurs  when  a  course  of  action  has  a  priority  of  zero. 

The  C2  Ontology 

The  first  component  of  IDA’s  study  is  an  ontology  (referred  to  as  the  GH  (Generic  Hub) 
ontology  from  now  on)  that  expresses  two  selected  C2  concepts  threats  and  operational 
readiness.  Both  concepts  are  central  to  decision  support  in  C2.  Their  fonnalization  in  the 
GH  ontology  will  support  demonstrations  of  how  applications  can  put  metadata  to  use. 

The  GH  ontology  is  based  on  the  Generic  Hub  data  model,  version  5  (GH5).  The  GH5  is 
a  data  model  developed  for  land  C2  operations  and  adopted  by  NATO  as  a  standard.1 
GH5  models  instances  and  types  of  battlefield  objects,  namely,  FACILITY,  FEATURE,  MATE¬ 
RIEL,  ORGANIZATION,  and  PERSON,  as  well  as  actions,  capabilities,  holdings,  locations,  and 
other  typical  C2  data.  Originally  intended  to  model  data  exchanges  of  brigade-and-above 
echelons,  the  model  is  capable  of  representing  information  down  to  the  billet  level. 

Basing  the  GH  ontology  on  the  GH5  is  a  significant  advantage,  even  aside  from  the  reuse 
of  a  well-accepted  standard.  Many  programs  already  use  the  GH5  (or  some  other  version 
of  the  GH),  proving  it  to  be  a  practical  data  model.  A  GH  ontology  is  therefore  of  imme¬ 
diate  interest  to  the  C2  community. 

The  GH5  is  specified  in  IDEF1X  notation.  It  models  the  C2  concepts  as  entities,  attrib¬ 
utes,  and  relationships.  The  GH5  specifies  data  elements,  their  valid  content,  and  rela¬ 
tionships  among  entities. 

IDEF1X  notation,  however,  goes  only  so  far  towards  making  data  understandable.  The 
GH5  may  contain  an  entity  named  FACILITY  and  what  it  means  is  explicated  in  terms  of  the 
attributes  and  relationships  of  FACILITY  in  the  model,  but  this  is  not  necessarily  the  totality 
of  what  at  the  semantic  level  is  encompassed  by  the  concept  of  a  facility.  This  study  is  an 
attempt  to  explore  the  ability  of  a  GH  ontology  to  express  those  other  semantic  facets  that 
traditional  data  modeling  techniques  do  not  cover. 


1  Originally  STANAG  5523,  but  that  standard  has  been  withdrawn  and  will  be  replaced  by  a  new 
STANAG  whose  number  is  indeterminate  as  of  this  time. 
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For  example,  many  GH5  data  elements  model  physical  properties  such  as  length,  height, 
width  and  weight.  The  GH  ontology  developed  in  this  study  formally  expresses  what  (if 
any)  physical  property  each  data  element  models,  and  what  semantic  interrelationships 
exist  among  properties.  For  example,  the  EQUIPMENT-TYPE  entity  has  attributes  such  as 
equipment-type-height,  equipment-type-width,  and  equipment-type-length.  The  ontology  explicitly 
defines  their  semantics  to  let  applications  know  that  these  attributes  are  linear  dimen¬ 
sions,  that  they  model  height,  width,  and  length,  respectively,  and  that  by  virtue  of  being 
linear  dimensions  other  operations  can  be  performed  on  them.  Thus,  the  GH  ontology 
expresses  formally  the  fact  that  length  and  width  can  be  multiplied  to  yield  an  area  and 
that  length,  width  and  height  can  be  combined  to  give  a  volume.  The  GH  ontology  also 
captures  the  fact  that  they  are  measured  in  meters  (as  per  the  GH5). 

The  GH  ontology  also  adds  information  on  which  elements  are  conceptually  equivalent 
and  which  are  not.  In  the  GH5,  bridge-span-quantity  and  hangar-area-quantity  are  both  inte¬ 
gers.  A  human  can  easily  infer  that  they  model  different  concepts;  an  application  cannot, 
unless  -  as  in  the  GH  ontology  -  available  metadata  explicitly  states  the  separate  concept 
each  data  attribute  denotes. 

To  be  of  use  to  an  application,  i.e.,  to  be  machine-process  able,  the  formalized  specifica¬ 
tions  of  an  ontology  must  be  written  in  an  appropriate  language.  The  most  common  ap¬ 
proach,  which  comes  from  research  in  knowledge  representation,  is  to  represent  an  ontol¬ 
ogy  as  a  set  of  frames.  The  emerging  standard  for  frame -based  ontology  specification  ap¬ 
pears  to  be  the  Open  Knowledge  Base  Connectivity  (OKBC)  protocol.  In  OKBC,  a  frame 
is  an  n-ary  relation,  of  which  there  are  several  forms: 

•  Classes,  which  describe  concepts.  Classes  are  roughly  equivalent  to  IDEF1X  enti¬ 
ties. 

•  Slots  which  describe  properties  of  classes.  Slots  are  roughly  equivalent  to 
IDEF1X  attributes. 

•  Facets,  which  describe  properties  of  slots.  Some  facets  are  roughly  equivalent  to 
IDEF1X  attribute  constraints,  e.g.,  enumerations,  value  ranges. 

•  Instances  of  classes.  An  ontology  containing  instances  is  referred  to  as  a  knowl¬ 
edge  base.  An  ontology  shows  how  to  reason;  a  knowledge  base  contains  infor¬ 
mation  about  which  one  might  want  to  reason. 

The  equivalences  noted  above  between  OKBC  and  IDEF1X  concepts  were  leveraged  to 
produce  the  GH  ontology.  The  following  mappings  are  used: 

•  Each  GH5  entity  is  represented  as  a  class  in  the  GH  ontology.  OKBC  supports 
class  hierarchies,  and  offers  more  freedom  and  flexibility  than  IDEF1X  subtypes 
(e.g.,  multiple  inheritances,  no  need  for  a  discriminator  column);  the  GH  ontology 
capitalizes  on  these  features. 

•  Each  GH5  attribute  is  represented  as  a  slot  in  the  GH  ontology. 

Furthermore,  the  GH  ontology  has: 

•  A  class  for  each  distinct  concept  modeled  by  attributes  (weight,  dimension,  radio 
frequency,  etc.). 
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•  A  class  hierarchy  for  expressing  relationships  between  physical  concepts  (e.g., 
length  x  width  =  area). 

•  A  class  hierarchy  for  expressing  units  of  measurement  and  their  interrelationships. 

•  The  ability  to  express  ordering.  For  example,  the  values  of  attribute  ammunition- 
type-calibre-code,  which  express  known  calibers  of  ammunition,  are  ordered  accord¬ 
ing  to  size. 

These  and  other  features  of  the  GH  ontology  are  an  indication  of  the  potential  benefits  for 
using  ontology-based  approaches  for  future  net-centric  infonnation  systems.  For  exam¬ 
ple,  the  adoption  of  the  GH  ontology  would  allow  those  Col’s  that  store  their  data  in  rela¬ 
tional  databases  that  conform  to  the  physical  schema  of  GH5  to  formally  capture  and  cen¬ 
trally  manage  their  business,  and  inference  rules  as  yet  another  resource,  instead  of  hav¬ 
ing  to  implement,  and  re-implement  them  for  each  GH5-accessing  application. 

The  GH  ontology  developed  in  this  study  is  implemented  using  Protege-2000,  a  free, 
open-source  software  ontology  editor  and  knowledge  base  access  tool.  Protege-2000  im¬ 
plements  the  OKBC  standard,  and  provides  a  sufficiently  powerful  model  to  support  de¬ 
velopment  of  the  kind  of  reasoning  needed  in  a  net-centric  environment. 

In  addition  to  the  GH  ontology  just  described,  the  IDA  team  has  also  begun  work  on  a 
more  general  C2  ontology.  It  is  written  on  top  of  the  GH  ontology.  In  other  words,  its 
concepts,  such  as  that  of  a  threat,  are  defined  solely  in  terms  of  concepts  expressed  by  the 
GH  ontology.  Reasoning  about  threats  in  the  C2  ontology  is,  therefore,  accomplished  in 
tenns  of  GH5  data  elements. 

The  IDA  team  recognizes  that  the  full  definition  of  concepts  such  as  these  is  highly  com¬ 
plex  and  would  require  extensive  resources.  For  this  reason,  whereas  the  GH  ontology 
fully  represents  the  GH5  and  every  GH5  element  has  an  analog  in  the  GH  ontology,  the 
C2  ontology  is  still  in  an  experimental  stage. 

A  Prototype  Net-Centric  System 

The  GH  and  C2  ontologies  IDA  has  developed  are  intended  in  part  to  demonstrate  that  an 
ontology  can  be  used  to  manage  information  overload  in  a  net-centric  environment.  How 
well  an  ontology  performs  remains  a  theoretical  question  until  an  application  is  devel¬ 
oped  that  uses  the  ontology. 

IDA  is  answering  this  question  by  implementing  an  agent-based  system  that  uses  the  on¬ 
tology  according  to  net-centric  precepts.  The  system  tests  the  viability  of  making  data 
understandable  within  the  C2  domain.  It  is  also  intended  as  a  paradigm  from  which  future 
developers  of  net-centric  software  may  gain  guidance  in  operational,  system,  and  techni¬ 
cal  architectures. 

The  prototype  comprises: 

•  A  set  of  mutually  friendly  organization  subsystems.  Each  subsystem  consists  of  a 
decision  support  application  plus  a  set  of  supporting  agents  that  access  the  C2 
knowledge  base  to  draw  inferences  relevant  to  decision  support.  These  agents 
provide  the  decision  support  application  either  periodically  or  on  demand,  as  ap¬ 
propriate  to  the  kind  of  data  on  which  the  agent  operates.  The  decision  support 
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application  accesses  a  DBMS  that  stores  a  GH5  data  set,  populated  with  continu¬ 
ally  updated  intelligence  on  situational  awareness. 

•  A  set  of  hostile  organization  subsystems  that,  under  certain  agent-defined  condi¬ 
tions,  may  be  considered  to  pose  a  threat  to  one  or  more  friendly  organizations. 

•  A  simulation  state  subsystem  responsible  for  maintaining  ground  truth  (e.g.,  each 
hostile  organization  subsystem  is  responsible  for  reporting  its  current  location  to 
the  simulation  state  subsystem). 

Each  decision  support  application  is  in  communication  with  the  agents  in  its  subsystem. 
These  agents  continually  monitor  the  knowledge  base  for  changes  that  should  be  brought 
to  the  attention  of  the  decision  support  application.  One  agent  is  devoted  to  threat  detec¬ 
tion.  When  conditions  in  the  knowledge  base  indicate  the  existence  of  a  threat,  it  notifies 
the  decision  support  application.  It  also  notifies  a  threat  response  agent,  which  formulates 
courses  of  action  that  seem  reasonable  in  light  of  the  threat.  The  threat  response  agent 
sends  these  courses  of  action  to  the  decision  support  application,  which  displays  them  to 
the  decision  maker.  See  Figure  ES-1. 
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Figure  ES-1.  Example  Courses  of  Action 

implemented  using  freely  available  software  components  and  standards, 
the  FIPA-OS  implementation  of  the  Foundation  for  Intelligent  Physical 
standards,  the  open  source  software  MySQF  relational  database  manage¬ 
ment  system,  and  the  Zeus  XMF  DTD  parser  generator.  Aside  from  these  components, 
the  system  contains  approximately  18,000  lines  of  Java  and  2,000  lines  of  other  lan¬ 
guages.  The  system  uses  C2  data  from  a  NATO  exercise  conducted  at  Ft.  Worth,  Texas. 

Conclusions  and  Directions 

Implementing  DoD’s  net-centric  data  strategy  poses  some  interesting  operational  and 
technical  challenges.  The  ontology  IDA  has  developed  addresses  the  degree  to  which  C2 
data  models  can  be  made  syntactically  and  semantically  understandable,  a  crucial  goal  of 
net-centricity. 

In  addition,  the  study  shows  that  an  ontology  can  be  employed  to  add  useful  semantics 
and  rules  to  underlying  data  models  in  a  reproducible  and  reusable  manner.  It  goes  with¬ 
out  saying  that  the  IDA  C2  ontology  does  not  incorporate  all  the  reasoning  capability  that 
it  could.  This  is  an  obvious  area  for  extension.  Further  research  is  necessary  to  assess  all 
the  C2  ontology  extensions  needed  to  be  useful  in  a  net-centric  environment.  Neverthe¬ 
less,  the  prototype  system  already  documents  preliminary  aspects  of  the  C2  ontology  util¬ 
ity. 


The  system  is 
These  include 
Agents  (FIPA) 
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Many  of  the  tools  IDA  used  to  create  the  ontologies  and  implement  the  prototype  are  of 
recent  origin.  They  are  of  reasonable  quality  but  not  validated  for  use  in  mission-critical 
applications;  they  crash  occasionally,  and  their  application  and  user  interfaces  are  evolv¬ 
ing.  DoD,  in  collaboration  with  industry  and  academia,  may  need  to  devote  additional 
resources  to  the  development  of  a  software  infrastructure  for  net-centricity. 
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1.  Introduction 


1.1  Background 

Throughout  history,  the  common  complaint  of  decision-making  war  fighters  has  been 
lack  of  information.  The  absence  of  a  common  and  complete  operational  picture  has  re¬ 
sulted  in  mishaps  ranging  from  minor  discomforts  to  the  Light  Brigade’s  infamous  blun¬ 
der.  Making  decisions  that  look  reasonable  in  hindsight  generally  requires  full  situational 
awareness,  something  war  fighters  traditionally  find  sorely  lacking. 

The  DoD’s  Global  Information  Grid  (GIG)  [GIG  2001]  is  a  significant  step  towards  the 
ability  to  provide  full  situational  awareness.  The  GIG,  which  aims  to  interconnect  all  war 
fighting  data,  is  a  major  paradigm  shift  for  the  DoD.  It  is  in  part  a  recognition  that  the  old 
strategy  of  centralized  data  administration  across  the  entire  department  is  impractical. 
There  exist  too  many  deeply  entrenched  cultures  within  DoD  to  create  fully  seamless  data 
exchanges  among  all  domains.  Data  sharing  cannot  be  mandated  in  such  an  environment. 
To  put  it  another  way,  data  cannot  be  “pushed”  against  someone’s  will.  Figure  1  illus¬ 
trates  this  environment.  Some  systems  are  developed  with  well-defined  interfaces  and  can 
exchange  data,  but  these  systems  tend  to  be  within  individual  domains.  Other  systems 
outside  the  domain  must  rely  on  data  content  in  a  globally  accessible  database.  With  no 
control  over  this  content,  other  systems  incur  risk  and  their  developers  often  find  that  du¬ 
plicating  the  content  is  less  costly,  or  as  least  better  justifiable,  than  using  the  existing 
data.  The  result  is  a  plethora  of  stovepipe  systems. 


Data  exchange  across  well-defined  interface 


Figure  1.  Data  Sharing  Today 

A  2003  memorandum  from  the  office  of  the  DoD  Chief  Information  Officer  presents  a 
new  vision  for  handling  data  [Stenbit  2003]  based  on  the  Semantic  Web  [Berners- 
Lee  2001].  In  this  vision,  the  DoD  will  nurture  individual  Communities  of  Interest  (Cols). 
Each  Col  will  be  responsible  for  identifying  the  set  of  data  it  manages.  Each  Col  will  be 
encouraged,  though  not  strictly  required,  to  make  its  data  visible  on  the  GIG.  The  DoD 
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believes  this  increased  data  visibility  will  better  enable  effective  decision-making  than  the 
current  environment. 

This  paradigm  is  a  double-edged  sword.  On  the  one  hand,  Cols  are  under  no  obligation  to 
make  data  visible,  nor  are  they  required  to  avoid  duplicating  existing  data  sources;  this 
gives  each  Col  considerable  freedom  and  flexibility.  On  the  other  hand,  the  existence  of 
data  from  one  Col  should  discourage  others  from  undertaking  the  effort  of  regenerating 
the  same  data  over  and  over. 

The  DoD  intends  Cols  to  encourage  the  growth  of  net-centricity.  Net-centricity  is  the  re¬ 
alization  of  network-centric  operations,  wherein  people,  processes,  and  systems  can 
freely  share  infonnation.  Net-centricity  represents  DoD’s  approach  to  abandoning  cen¬ 
tralized  data  infonnation  and  consequent  stovepipe  systems.  The  growth  of  net-centricity 
can  lead  to  more  data,  better  managed. 

[Stenbit  2003]  establishes  seven  goals,  the  achievements  of  which  are  crucial  to  achieving 
net-centricity.  The  following  is  a  summary  of  these  goals: 

1 .  Make  data  visible:  Users  and  applications  must  be  able  to  discover  the  existence 
of  data. 

2.  Make  data  accessible:  There  must  exist  shared  spaces  to  which  users  and  applica¬ 
tions  can  post  data. 

3.  Institutionalize  data  management:  Approaches  to  managing  data  are  incorporated 
into  DoD  processes  and  practices.  Note  that  this  goal  covers  only  data  manage¬ 
ment,  not  the  data  itself. 

4.  Enable  data  to  be  understandable:  Users  and  applications  must  be  able  to  compre¬ 
hend  data  structure  and  semantics. 

5.  Enable  data  to  be  trusted:  Users  and  applications  must  be  able  to  determine  and 
assess  the  degree  to  which  they  must  trust  each  datum.  In  other  words,  attributes 
such  as  security  and  pedigree  must  be  known. 

6.  Support  data  interoperability:  Metadata  must  be  available  to  allow  mediation  or 
translation  of  data  between  interfaces  where  necessary. 

7.  Be  responsive  to  user  needs:  Approaches  will  evolve  in  response  to  user  feedback. 

Figure  2  shows  how  realizing  these  goals  will  help  achieve  net-centricity.  The  area  inside 
the  dashed  box  denotes  a  single  Col.  Within  this  area,  all  systems  communicate  using 
well-defined  interfaces,  just  as  in  Figure  1 .  This  is  possible  because  the  Col  can  exert 
control  over  the  systems  it  defines,  mandating  standards  as  it  sees  fit.  However,  instead  of 
simply  making  its  data  content  available,  a  system  within  a  Col  publishes  its  data  to  a 
shared  space.  The  shared  space  contains  not  just  the  data  (Data  Contents)  but  also  infor¬ 
mation  that  can  help  other  systems  discover  if  the  data  meets  their  needs  (Discovery 
Metadata  Catalog)  and  information  on  how  to  interpret  the  data  (Structural  Metadata). 
Rather  than  creating  fixed  interfaces,  other  systems  may  dynamically  search  for  data  - 
i.e.,  browse  through  the  discovery  metadata  catalogs  in  a  known  set  of  shared  spaces  - 
and  choose  the  set  that  best  fits  their  current  situation.  Systems  A  and  B  are  still  free  to 
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communicate  through  their  well-defined  interfaces,  if  that  is  most  efficient,  but  they  are 
being  much  more  systematic  about  the  availability  and  nature  of  their  data. 


Figure  2.  Net-Centric  System  Execution  Concept 


Net-centricity  provides  an  excellent  foundation  for  improving  decision  support  applica¬ 
tions.  A  decision  support  system  can  continually  search  the  GIG  for  whatever  data  is  most 
appropriate,  from  information  on  the  next  town  to  prospects  for  resupply  from  halfway 
across  the  globe. 

By  the  same  token,  net-centricity  carries  the  hazard  of  information  overload  for  the  war 
fighter.  Increasing  the  amount  of  information  available  to  a  decision  support  system  -  as 
the  GIG  is  intended  to  do  -  increase  the  amount  of  information  that  system  must  process. 
A  decision-making  war  fighter  may  then  see  a  corresponding  increase  in  the  amount  of 
information  presented  to  him.  Any  extra  information  he  must  process  increases  the  time 
he  needs  to  reach  a  decision.  Given  that  the  GIG  is  globally  connected,  and  that  many 
decision  support  systems  rely  on  local  information,  it  is  reasonable  to  expect  that  decision 
support  systems  of  the  future  will  have  orders  of  magnitude  more  information  available. 
Clearly,  these  systems  must  be  able  to  decide  what  information  is  relevant  and  discard  the 
rest.  Otherwise,  future  decision  makers  will  spend  so  much  time  analyzing  data  that  they 
will  be  unable  to  make  timely  decisions. 

The  goal  of  making  data  understandable  addresses  infonnation  overload.  Understandabil- 
ity  means  more  than  structural  and  semantic  descriptions.  It  implies  an  ability  to  deter¬ 
mine  the  value  of  data.  An  application  that  is  pulling  data  must  be  able  to  filter  the  data 
based  on  perceived  need. 
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The  net-centric  strategy  identities  Col-specific  ontologies  as  one  facet  of  making  data 
understandable.  An  ontology  is  an  expression  of  the  nature  and  relations  of  some  entity  or 
set  of  entities.  Examples  of  what  an  ontology  encompasses  include  data  categorization 
schemes,  thesauri,  vocabularies,  and  taxonomies.  The  major  purpose  of  an  ontology  in  a 
net-centric  environment  is  to  describe  the  data  of  a  Col  in  ways  that  promote  use  of  that 
data  by  systems  outside  the  Col.  An  ontology  contributes  to  the  discovery  metadata  cata¬ 
log  by  helping  other  systems  locate  data  content  describing  concepts  of  interest.  For  ex¬ 
ample,  a  system  searching  for  data  describing  a  tank  might  find  a  discovery  metadata 
catalog  listing  a  tank  as  a  known  concept  in  a  shared  space.  Of  course,  the  system  needs 
to  know  if  the  tank  in  question  is  a  tracked  fighting  vehicle  or  a  container  of  fuel;  ontolo¬ 
gies  in  the  fonn  of  thesauri  and  vocabularies  help  disambiguate. 

An  ontology  also  contributes  to  structural  metadata  by  describing  entities  and  their  rela¬ 
tionships.  A  (tracked  fighting  vehicle)  tank  has  a  (fuel)  tank.  Taxonomies  of  a  well- 
defined  ontology  make  such  relationships  clear,  and  allow  systems  to  draw  inferences 
such  as  the  capacity  of  the  (fuel)  tank  of  a  tank. 

To  be  useful  in  a  net-centric  environment,  an  ontology  must  be  formal  and  executable. 
System  developers  have  often  employed  ontologies  informally  as  part  of  system  docu¬ 
mentation  (e.g.,  drawings  of  data  models),  which  may  suffice  for  a  human  reading  that 
document  but  of  no  use  to  a  decision  support  software  application.  The  premise  of  an  on¬ 
tology  in  the  net-centric  data  strategy  is  that  other  systems  can  access  it  to  determine 
whether  the  data  it  describes  is  useful  or  not. 

The  DoD  CIO  envisions  that  each  Col  will  develop  and  maintain  ontologies  of  its  data 
and  register  those  ontologies  in  a  central  DoD  Metadata  Registry.  Other  systems  search 
this  registry  (or  registries;  several  may  exist)  when  they  need  information.  The  registry 
both  describes  the  type  of  information  (the  details  are  in  the  structural  metadata  catalog) 
and  the  shared  space  in  which  to  find  it.  Other  systems  use  registries  to  identify  likely 
data  sources,  then  use  a  shared  space  to  retrieve  data  and  determine  its  meaning. 

The  power  of  ontologies,  then,  will  stem  from  their  ability  to  promote  dynamic  access  to 
data.  Applications  will  no  longer  be  constrained  by  a  fixed  set  of  interfaces.  Each  time 
they  desire  information,  they  can  search  as  broadly  -  or  as  narrowly  -  as  is  appropriate  to 
their  context. 

The  underlying  assumption  is  that  ontologies  can  be  sufficiently  expressive  to  let  applica¬ 
tions  determine  the  relevance  of  data.  An  ontology  is  a  specification  of  data  structure  and 
semantics.  To  support  net-centricity,  an  ontology  will  have  to  be  written  using  a  fonnal 
language  that  is  not  only  understandable  to  humans  but  also  machine-process  able.  When 
that  is  the  case,  an  application  looking  for  some  type  of  data  ought  to  be  able  to  use  an 
ontology  to  detennine: 

1 .  Whether  a  Col  offers  that  data. 

2.  Whether  or  not  the  data  is  somehow  better  (e.g.,  more  trustworthy)  than  seem¬ 
ingly  equivalent  data  from  another  Col. 

3.  Whether  the  data  is  in  a  form  that  will  be  useful. 
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4.  How  the  data  can  be  retrieved. 

No  general-purpose  solutions  exist  to  all  these  problems.  Much  research  has  been  de¬ 
voted  to  aspects  of  them,  and  many  researchers  have  proposed  solutions  that  have  at  least 
been  demonstrated  to  work  in  constrained  environments.2  Much  of  the  recent  interest  in 
ontologies  has  arisen  out  of  the  World  Wide  Web  and  the  belief  that  ontologies  will  be 
useful  in  electronic  commerce.  How  the  results  from  that  community  translate  to  military 
applications  remains  to  be  seen.  A  model  builder  searching  eBay  for  tanks  may  find  items 
for  sale  in  categories  like  Fuel  Tanks  and  Women’s  Shirts  (tank  tops)  as  well  as  Toys  and 
Hobbies.  The  cost  to  society  of  these  improper  hits  is  low.  The  war  fighter  whose  deci¬ 
sion  support  system  mistakes  a  fuel  container  for  a  tracked  fighting  vehicle  might  not  be 
so  lucky. 

Tim  Berners-Lee,  the  creator  of  the  World  Wide  Web,  has  said  that  his  original  vision  of 
the  Web  isn’t  at  all  what  exists  today.  He  wanted  the  development  of  a  Semantic  Web  in 
which  applications  could  relate  and  differentiate  concepts  [Berners-Lee  2001].  This  sort 
of  web  could  help  provide  applications  with  the  necessary  technology  to  achieve  DoD’s 
vision.  This  paper  explores  semantic  web  concepts  in  the  context  of  decision  support. 

1.2  Purpose  of  the  Document 

The  Institute  for  Defense  Analyses  (IDA)  has  undertaken  an  exploration  of  how  ontolo¬ 
gies  might  be  used  in  a  net-centric  environment.  The  objective  of  this  exploration  is  to 
determine  the  validity  of  the  assumption  that  ontologies  can  be  sufficiently  expressive  to 
determine  the  relevance  of  data.  The  purpose  of  this  document  is  to  describe  progress 
made  to  date,  to  discuss  steps  that  remain  to  be  taken  to  complete  this  exploration,  and  to 
identify  issues  that  need  to  be  resolved  to  make  ontologies  live  up  to  their  potential  in 
contributing  to  net-centricity. 

A  related  issue  is  whether  an  ontology  adds  expressive  power  above  and  beyond  existing 
data  modeling  technologies,  and  whether  the  expense  of  adding  expressiveness  is  justi¬ 
fied  -  i.e.,  can  ontologies  be  built  quickly  and  cheaply?  To  state  the  issue  in  concrete 
terms:  why  use  ontologies  instead  of  relational  database  management  systems?  Any  in¬ 
formation  that  can  be  described  in  an  ontology  can  also  be  stored  in  a  DBMS  (the  ontol¬ 
ogy  editor  tool  used  in  this  project  offers  the  option  of  storing  an  ontology  in  a  DBMS). 
Ontology  technology  must  offer  something  relational  technology  does  not. 

This  paper  does  not  directly  discuss  the  merits  of  ontologies  vs.  relational  databases.  To 
do  so  would  be  unfair:  ontology  tools  are  not  as  mature  as  relational  database  tools.  Any 
comparisons  would  be  based  mostly  on  what  research  says  is  computationally  possible. 
That  gives  no  satisfactory  answer  to  the  question  of  development  cost.  In  any  case,  this 
project  was  begun  after  DoD  had  already  decided  to  develop  ontologies  for  the  GIG.  The 
issue  of  their  cost  is  therefore  irrelevant  to  our  objectives. 


The  Control  of  Agent  Based  Systems  (CoABS)  program  is  one  example.  See 
http://coabs.globalinfotek.com/.  which  provides  an  overview  of,  and  links  to,  several  relevant  projects. 
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Certain  places  in  the  document,  especially  Section  5,  cover  the  merits  of  ontologies  in  a 
general  way.  Where  possible,  we  show  how  and  why  ontologies  increase  expressive 
power.  However,  we  do  so  qualitatively. 

1.3  Intended  Audience 

The  intended  audience  for  this  document  includes  everyone  contributing  to  achieving  the 
DoD  net-centric  data  strategy,  especially: 

1 .  Analysts  developing  ontologies. 

2.  Designers  and  developers  of  decision  support  systems. 

3.  Designers  and  developers  of  the  GIG. 

4.  Department  of  Defense  officials  responsible  for  implementation  of  the  DoD  CIO’s 
net-centric  data  strategy. 

This  document  assumes  familiarity  with  entity-relationship  modeling,  and  with  command 
and  control  (C2)  concepts.  Familiarity  with  the  Generic  Hub  information  exchange  data 
model  [NATO  2002]  is  helpful  but  not  required. 

1.4  Organization  of  this  Document 


This  document  is  organized  as  follows: 

•  Section  1  (this  section)  presents  concepts,  potential,  and  liabilities  of  a  net-centric 
environment. 

•  Section  2  gives  an  overview  of  the  project  IDA  has  undertaken  to  address  selected 
liabilities. 

•  Section  3  gives  a  detailed  discussion  of  C2  and  C2-related  ontologies  IDA  has 
created.  These  ontologies  illustrate  what  a  community  of  interest  might  publish  on 
the  GIG. 

•  Section  4  discusses  the  prototype  system  IDA  has  created  to  demonstrate  an  op¬ 
erational  architecture  for  use  of  the  ontology. 

•  Section  5  discusses  the  implications  of  the  work  performed  to  date,  then  presents 
areas  for  future  work. 
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2.  Project  Overview 


This  task  is  part  of  work  currently  being  performed  at  IDA,  in  support  of  the  United 
States  Anny,  aimed  at  building  non-trivial  work  products  that  implement  portions  of  a 
net-centric  environment.  These  work  products  are  focused  on  the  net-centric  data  strategy 
goal  of  making  data  understandable  (Goal  4)  -  in  particular  Goal  4.1,  defining  Col- 
specific  ontologies.  The  current  task  explores  the  feasibility  of  building  an  ontology  that 
would  be  of  use  to  war  fighters.  The  existence  of  an  ontology  of  this  nature  is  essential  to 
determining  the  viability  of  Goal  4  using  today’s  technology,  and  to  understanding  any 
technical  innovations  that  are  necessary  before  it  can  be  realized. 

This  project  documents  the  viability  of  Goal  4  and  the  lessons  learned  that  will  guide  oth¬ 
ers  in  developing  ontologies  and  systems.  The  project  makes  recommendations  on  tech¬ 
nologies  for  developing,  maintaining,  propagating,  and  accessing  ontologies.  It  describes 
a  system  architecture  for  accessing  the  ontologies  in  a  net-centric  environment. 

This  project  documents  the  following  work  products: 

1.  An  ontology  for  the  domain  of  command  and  control  (C2).  C2  is  a  domain  with  a 
long,  important  history  in  warfare.  It  constitutes  an  area  for  which  a  Col  will  almost 
certainly  exist,  perhaps  at  the  Service  level,  perhaps  at  the  Joint  level  for  all  of  DoD. 

The  ontology  developed  in  this  project  is  based  on  the  Generic  Hub  (GH),  an  ex¬ 
isting  Information  Exchange  Data  Model  (IEDM),  and  includes  all  GH  entities, 
attributes,  and  relationships.  In  that  sense  it  is  a  complete  C2  ontology.  However, 
IEDMs  typically  consist  of  low-level  concepts.  They  do  not  define  higher-level 
abstract  notions  that  are  of  interest  to  a  war  fighter.  For  example,  although  the  GH 
models  the  concept  of  a  battlefield  object  and  contains  enough  information  to  de¬ 
termine  whether  one  battlefield  object  presents  a  threat  to  another,  it  does  not  ex¬ 
plicitly  model  the  concept  of  threat  -  something  a  battlefield  commander  needs  to 
know. 

The  results  of  the  task  include  selected  high-level  concepts  in  the  C2  ontology. 
The  presence  of  these  concepts  demonstrates  the  ability  of  a  C2  ontology  to 
model  complex  concepts  and  to  support  reasoning  about  those  concepts. 

2.  A  prototype  system  of  decision  support  applications.  Creating  a  C2  ontology  is  a 
useful  exercise  in  its  own  right  -  it  aids  in  the  study  of  fonnal  relationships  be¬ 
tween  entities  -  but  does  not  demonstrate  that  the  ontology  is  formal  or  complete 
enough  to  be  useful.  Other  systems  must  be  able  to  use  the  ontology  to  identify, 
search,  access,  and  interpret  C2  data.  The  mechanisms  by  which  these  actions  oc¬ 
cur  must  not  take  place  using  the  proverbial  well-defined  interface  of  Figure  1; 
they  must  happen  using  the  paradigm  of  Figure  2. 

The  IDA  team  has  built  a  prototype  system  that  uses  the  C2  ontology  in  confor¬ 
mance  with  the  architectural  principles  of  net-centricity.  The  system  demonstrates 
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how  to  avoid  information  overload  through  ontology-based  decision  support  ap¬ 
plications. 

The  prototype  system  is  not  a  production  level  application;  that  would  be  well  be¬ 
yond  the  scope  of  IDA’s  task.  It  has  been  implemented  to  highlight  operational, 
system,  and  technical  architectures  that  other  developers  of  net-centric  systems 
might  find  useful. 

3.  Documentation  of  Practices  and  Principles.  In  addition  to  the  description  and 
analysis  related  to  the  two  products  mentioned  above,  the  document  also  contains 
lessons  learned  in  developing  them,  which  hopefully  future  developers  of  ontolo¬ 
gies  and  ontology-based  applications  will  find  helpful.  The  report  contains  both  a 
methodology  for  developing  an  ontology,  and  a  methodology  for  developing  on¬ 
tology-based  applications.  The  report  also  provides  recommendations  on  tech¬ 
nologies  and  how  they  can  be  employed. 
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3.  A  C2  Ontology 


In  a  net-centric  environment,  where  an  ontology  must  be  software  interpretable,  the  on¬ 
tology  must  be  formally  defined.  Formality  implies  rigorously  defined  structures  and  se¬ 
mantics.  Extensive  fonnalization  of  C2  structures  and  semantics  has  been  accomplished 
in  the  data  layer  specifications  for  information  exchanges  among  C2  databases.  Rather 
than  to  reinvent  these  C2  concepts,  IDA  has  chosen  to  base  its  C2  ontology  on  an  existing 
formal  C2  data  model.  This  C2  data  model  is  the  Generic  Hub  (GH)  Information  Ex¬ 
change  Data  Model  (IEDM). 

3.1  Background  on  the  Generic  Hub 

The  GH  was  developed  by  the  Army  Tactical  Command  and  Control  Information  System 
(ATCCIS)  to  support  land  C2  operations  in  a  multinational  environment  for  echelons  to 
include  Brigade,  Corps  and  above.  It  emphasizes  data  that  national  armies  would  share 
under  such  conditions  and  purposely  omits  details  traditionally  handled  by  national  C2 
systems,  such  as  personnel-related  information.  The  model  also  reflects  the  philosophy 
that  planning  documents  must  be  boiled  down  to  the  specific  actions  contained  therein, 
and  mapped  to  who  does  the  action,  against  whom,  with  what,  where,  and  when. 

For  the  development  of  the  C2  ontology,  the  IDA  team  chose  version  5.2  of  the  Generic 
Hub  (released  January  31,  2003),  hereafter  referred  to  as  the  GH5.  The  GH5  is  the  NATO 
standard  IEDM  for  joint  and  coalition  operations.  It  has  also  been  adopted  by  the  Army’s 
Future  Combat  Systems  (FCS)  program,  and  has  been  used  at  the  Naval  Postgraduate 
School  and  the  Naval  Undersea  Warfare  Center  (NUWC)  for  various  data  interoperability 
projects. 

Figure  3  uses  an  entity-relationship  diagram  to  show  selected  GH5  entities  and  relation¬ 
ships,  in  particular  those  that  play  a  role  in  this  paper.  The  GH5  models  battlefield  ob¬ 
jects.  Each  instance  of  a  battlefield  object  is  modeled  as  an  OBJECT-ITEM.  There  are  five 
kinds  of  battlefield  objects:  FACILITY,  FEATURE,  MATERIEL,  PERSON,  and  ORGANISA¬ 
TION.  An  OBJECT-ITEM  has  one  or  more  types.  A  type  is  modeled  as  an  instance  of 
OBJECT-TYPE,  which  is  a  super  type  of  five  kinds  of  battlefield  object  types  that  corre¬ 
spond  to  the  different  types  of  battlefield  objects,  i.e.,  FACILITY-TYPE,  FEATURE-TYPE, 
MATERIEL-TYPE,  PERSON-TYPE,  and  ORGANISATION-TYPE. 

Each  of  the  type  entities  has  attributes  (not  shown)  that  further  categorize  the  type  as  one 
of  a  set  of  enumerated  elements.  For  example,  a  PERSON-TYPE  may  be  DETNEE  (a  de¬ 
tainee,  i.e.,  a  person  in  custody),  GOVEMP  (a  government  employee),  JRNLST  (a  journal¬ 
ist),  or  any  of  nineteen  other  values.  Instances  are  not  mutually  exclusive.  The  GH5 
would  model  a  journalist  in  custody  as  an  instance  of  PERSON  associated  with  two  in¬ 
stances  of  PERSON-TYPE,  the  first  with  an  attribute  value  of  JRNLST  and  the  second  with 
a  value  of  DETNEE. 
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Figure  3  shows  associative  entities,  i.e.,  those  that  model  attributes  of  many-to-many  rela¬ 
tionships,  in  italics.  For  example,  the  HOLDINGS  entity  shows  the  association  between  an 
OBJECT-ITEM  and  the  OBJECT-TYPEs  it  possesses.  One  attribute  of  HOLDINGS  is  the  quan¬ 
tity  held.  For  example,  that  a  battalion  holds  a  certain  quantity  of  ammunition  is  modeled 
by  an  association  between  the  instance  of  ORGANISATION  modeling  the  battalion  and  the 
instance  of  MATERIEL-TYPE  modeling  that  kind  of  ammunition;  the  quantity  is  captured 
as  an  attribute  of  the  instance  of  the  relationship  between  OBJECT-ITEM  and  OBJECT- 
TYPE.  (The  GFI5  can  also  model  associations  between  instances  of  OBJECT-ITEM;  a  bat¬ 
talion  can,  if  it  wishes,  track  every  individual  bullet.  Such  detail  is  seldom  worth  the  ef¬ 
fort,  however,  and  Figure  3  does  not  show  the  GH5  elements  for  modeling  it.) 
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Figure  3.  Entity-Relationship  Model  of  Selected  GH5  Elements 

The  potential  abilities  and  effects  of  each  battlefield  object,  and  each  battlefield  object 
type,  are  described  as  a  set  of  CAPABILITY  instances.  Each  CAPABILITY  instance  denotes 
some  physical  ability  or  effect;  the  GH5  enumerates  a  standard  set.  There  are  capabilities 
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that  describe  storage,  mobility,  surveillance,  firepower,  mission,  and  engineering  abilities. 
An  OBJECT-TYPE  has  a  nominal  set  of  capabilities  (OBJECT-TYPE-CAPABILITY-NORM).  An 
OBJECT-ITEM  has  an  actual  set  of  capabilities  (OBJECT-ITEM-CAPABILITY). 


A  battlefield  object  has  a  location.  The  GH5  models  location  as  an  association  between 
OBJECT-ITEM  and  LOCATION.  The  LOCATION  entity  is  the  super  type  of  a  set  of  entities 
that  model  geodetic  locations  either  as  a  point  or  as  a  shape.  A  point  can  be  referenced  in 
either  two  or  three  dimensions.  A  shape  can  be  either  two  or  three  dimensional.  Figure  4 
shows  the  different  types  of  locations  the  GH5  models. 
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Figure  4.  GH5  Location  Entity  Hierarchy 

Except  for  OBJECT-TYPE-CAPABILITY-NORM,  all  GH5  associative  entities  have  a  relation¬ 
ship  to  REPORTING-DATA.  REPORTING-DATA  is  a  central  element.  It  is  shown  in  Figure  5. 
Its  attributes  provide  for  time-ordered  specifications.  For  example,  the  location  of  an  in¬ 
stance  of  OBJECT-ITEM  over  time  is  modeled  as  a  set  of  relationships  between  that  in¬ 
stance  of  OBJECT-ITEM  and  a  set  of  instances  of  LOCATION.  Each  OBJECT-ITEM- 
LOCATION  has  an  associated  REPORTING-DATA  stating  the  day  and  time  for  which  the  re¬ 
lationship  is  valid,  i.e.,  the  time  when  the  OBJECT-ITEM  was  reported  to  be  at  a  Location. 
Similarly,  each  OBJECT-ITEM-CAPABILITY  relationship  has  an  associated  REPORTING- 
DATA  instance  stating  the  time  when  the  OBJECT-ITEM  was  observed  to  have  the  stated 
CAPABILITY.  There  is  however  no  REPORTING-DATA  associated  with  an  OBJECT-TYPE- 
CAPABILITY-NORM.  OBJECT-TYPE-CAPABILITY-NORM  describes  nominal,  not  observed, 
capability. 


The  REPORTING-DATA  entity  has  attributes  reporting-date  and  reporting-time  that  model 
when  an  observation  was  made,  but  REPORTING-DATA  does  has  model  the  period  during 
which  the  observation  is  valid.  That  aspect  is  handled  in  one  of  two  subtypes: 
REPORTING-DATA-ABSOLUTE-TIMING  and  REPORTING-DATA-RELATIVE-TIMING.  As  their 
names  imply,  they  model  reporting  data  in  either  absolute  or  relative  terms.  The  effective- 
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Figure  5.  GH5  Reporting  Data  Entities  and  Attributes 

date  and  effective-time  attributes  of  REPORTING-DATA-ABSOLUTE-TIMING  model  the  effec¬ 
tive  starting  moment,  and  the  timing-duration  attribute  lets  the  effective  ending  moment  be 
calculated.  The  effective  time  of  relative  recording  data  is  specified  using  an  offset 
(timing-offset-duration)  with  respect  to  an  instance  of  an  ACTION-TASK. 

The  GH5  can  model  planned  and  actual  occurrences  of  activities.  These  are  modeled  as 
instances  of  ACTION.  ACTION  has  two  subtypes: 

1.  ACTION-EVENT,  denoting  a  past  or  present  “incident,  phenomenon  or  occasion  of 
military  significance”  for  which  no  planning  is  known. 

2.  ACTION-TASK,  denoting  a  past,  present,  or  future  activity  for  which  planning  is 
known. 

An  ACTION  can  be  associated  with  an  ORGANISATION.  The  relationship  between  the  two 
describes  the  role  of  the  ORGANISATION  with  respect  to  the  ACTION  (approves,  controls, 
initiates,  etc.).  An  ACTION  consumes  resources.  These  may  be  specified  either  as  resource 
types  or  as  actual  items,  depending  (usually)  on  whether  or  not  the  ACTION  is  a  template. 
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Similarly,  an  ACTION  has  objectives.  These  also  may  be  specified  either  as  resource  types 
or  as  actual  items. 

3.2  A  GH  Ontology 

The  ontologies  currently  being  explored  in  academia,  government  research  institutions, 
and  industry  are  expected  to  support  basic  reasoning  tasks  by  allowing  users  and  applica¬ 
tions  to  draw  inferences  about  data.  The  GH  is  an  IEDM.  It  provides  a  suitable  point  of 
departure  for  an  ontology  insofar  as  its  entities,  attributes,  and  relationships  categorize 
concepts.  However,  like  any  IEDM,  the  GH  lacks  the  fonnal  inference  capabilities  ex¬ 
pected  of  an  ontology. 

3.2.1  Business  Rules 

IDA’s  early  investigations  therefore  focused  on  identifying  GH  business  rules  and  figur¬ 
ing  out  how  to  formalize  them  to  support  inferencing.  In  practice,  it  is  not  difficult  to  un¬ 
cover  many  such  rules.  Most  entities,  attributes,  and  relationships  in  the  distributed  GH5 
model  have  explicatory  textual  definitions.  Some  of  these  definitions  provide  hints  in¬ 
tended  for  application  implementers  but  equally  useful  for  ontology  developers.  Other 
sources  for  business  rules  come  from  GH  naming  conventions.  The  following  are  some 
examples  of  business  rules  IDA  uncovered  and  formalized. 

Much  of  the  GH  models  physical  phenomena.  It  follows  that  applications  using  a  GH- 
based  ontology  would  want  to  reason  about  relationships  among  the  sorts  of  physical  en¬ 
tities  the  GH  models.  For  instance,  the  attribute  hanger-area-quantity  of  the  AIRFIELD  entity 
measures  (obviously)  the  area  in  a  hanger  available  for  storing  aircraft;  the  textual  defini¬ 
tion  of  this  attribute  further  states  that  the  units  of  this  attribute  are  square  meters.  The 
GH  also  includes  an  AIRCRAFT-TYPE  entity,  attributes  of  which  include  its  dimensions  - 
height,  length,  and  width  -  also  in  meters.  Useful  inferences  from  this  information  would 
include: 

1 .  Can  an  airfield  store  a  particular  type  of  aircraft? 

2.  Can  a  squadron  of  aircraft  of  the  same  type  be  stored  at  an  airfield? 

3.  Can  several  squadrons  of  aircraft  of  mixed  types  be  stored  at  an  airfield? 

The  GH  contains  data  elements  to  model  the  first  and  second  inference,  but  not  the  third. 
Thus  the  ontology  must  include  a  framework  through  which  inferences  related  to  physical 
properties  of  entities  can  be  made.  For  the  aircraft  example,  the  ontology  must  support 
modeling  of  measurable  concepts  (dimensions  and  area)  and  units  of  measurement.  It 
must  be  possible  to  infer  that  storing  aircraft  requires  knowing  the  area  each  aircraft  oc¬ 
cupies,  that  quantity  of  aircraft  stored  requires  an  area  equal  to  at  most  the  sum  of  area  of 
each  aircraft,  and  that  the  units  of  measurement  of  area  are  equivalent  -  or  if  they  are  not, 
how  to  convert  between  them. 

Equally  important  is  knowing  what  is  not  relatable.  In  the  GH,  an  attribute  whose  name 
ends  with  -quantity  denotes  some  measurable  quantity.  However,  quantities  are  not  unit 
less,  and  unless  the  units  are  equal  or  convertible,  the  attributes  they  measure  are  not 
comparable.  The  attribute  bridge-span-quantity  is  defined  as  follows: 
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The  numeric  value  that  represents  the  number  of  sections  that  a  specific  Bridge 
may  have. 

Obviously  hangar-area-quantity  has  no  relationship  to  bridge-span-quantity,  despite  the  simi¬ 
larity  of  their  names.  It  follows  that  the  ontology  must  be  precise  as  to  conceptual  interre¬ 
latedness  at  the  attribute  level,  not  just  at  entity  level  as  is  true  for  the  GH.  The  GH  speci¬ 
fies  a  domain  for  each  attribute,  and  shares  domains  across  attributes  where  appropriate. 
For  example,  it  specifies  separate  domains  for  the  latitude  and  longitude  coordinate  at¬ 
tributes  of  an  ABSOLUTE-POINT.  Latitude  is  a  9-digit  number  with  6  digits  following  the 
decimal  point,  and  longitude  is  a  10-digit  number  with  6  digits  following  the  decimal 
point,  a  formulation  that  is  quite  logical  when  one  recalls  that  longitudes  have  a  range 
twice  as  large  as  latitudes. 

However,  the  GH  is  not  always  precise  enough.  It  uses  the  same  domain  for  EQUIPMENT- 
TYPE  height,  width,  and  length,  implying  interchangeability  among  the  three  aspects  of 
size.  It  also  uses  some  domains  named  for  their  representation.  The  loaded-weight-quantity 
and  unloaded-weight-quantity  attributes  of  EQUIPMENT-TYPE  have  domain  qty-non-negative- 
real-12-3-optional.  As  it  happens,  these  two  attributes  model  equivalent  concepts  (weight) 
but  the  GH  also  uses  that  domain  for  the  capability-norm-quantity  attribute  of  OBJECT-TYPE, 
which  can  model  weight  but  can  model  other  properties  too.  Most  string-valued  domains 
are  named  for  their  representation;  both  action-name  and  physical-address-street-name  use 
the  domain  name-50  although  they  are  clearly  not  interchangeable.  Such  genericity  is  ac¬ 
ceptable  in  an  IEDM,  but  diminishes  the  power  of  an  ontology. 

IDA  formulated  business  rules  that  segregated  domains  insofar  as  was  possible.  The  re¬ 
sult  is  that  the  ontology  can  only  be  used  to  draw  inferences  among  properly  related  con¬ 
cepts. 

3.2.2  The  Knowledge  Model 

After  deciding  to  formalize  certain  GH  concepts,  IDA  needed  to  choose  a  knowledge 
model  in  which  to  represent  the  ontology.  The  IDEF1X  model  [NIST  1993]  used  to  rep¬ 
resent  the  GH5  was  inadequate.  GH5’s  designers  did  not  formally  state  many  of  the  busi¬ 
ness  rules  needed  in  an  ontology  because  they  could  not. 

The  emerging  standard  for  representing  ontologies  appears  to  be  the  Open  Knowledge 
Base  Connectivity  (OKBC)  protocol  [Chaudhri  1998],  In  this  model,  derived  from  earlier 
work  on  the  Ontolingua  server  [Farquhar  1997],  knowledge  is  represented  as  a  set  of 
frames.  A  frame  is  an  n-ary  relation,  of  which  there  are  several  standard  forms: 

•  Classes,  which  describe  concepts.  Classes  are  organized  hierarchically.  There  is  a 
special  class  called:  THING  that  is  the  super  class  of  all  other  classes. 

•  Slots,  which  describe  properties  of  classes.  A  slot  is  said  to  be  attached  to  a  class. 
A  slot  has  a  value. 

•  Facets,  which  describe  properties  of  slots. 

•  Instances  of  classes. 
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These  forms  are  not  dissimilar  to  the  elements  of  an  entity-relationship  model.  As  will 
become  clear,  they  are  far  more  powerful. 

Slots  are  independent  of  classes.  If  an  ontology  contains  a  slot  S,  S  may  be  shared  among 
several  classes.  The  implication  is  that  all  the  classes  have  a  common  property.  This  is 
unlike  the  IDEF1X  model,  where  an  attribute’s  name  space  is  that  of  its  entity.  Two  enti¬ 
ties  may  have  a  name  attribute;  but,  though  a  reader  might  assume  from  the  common 
names  that  the  attributes  model  the  same  kind  of  information,  nothing  in  IDEF1X  en¬ 
forces  or  even  alludes  to  that  assumption.3  In  OKBC,  then,  changing  a  slot  implies  that 
the  change  applies  to  all  classes  containing  that  slot. 

There  are  two  kinds  of  slots:  template  slots  and  own  slots.  A  template  slot  is  attached  to  a 
class.  It  is  inherited  by  all  subclasses  of  that  class.  An  own  slot  is  attached  to  a  frame.  An 
own  slot  describes  a  property  of  a  frame,  and  is  not  inherited  if  attached  to  a  class.  An 
own  slot  is  useful  for  specifying  something  about  a  specific  frame:  some  property  of  a 
class  or  slot  (e.g.,  a  human-readable  name).  Template  slots  have  the  interesting  character¬ 
istic  of  becoming  an  own  slot  for  an  instance  of  a  class.  For  example,  if  an  ontology  has  a 
slot  S,  it  would  be  useful  to  provide  S  with  an  own  slot  to  denote  a  name  for  S.  If  the  on¬ 
tology  has  a  class  C,  and  C  has  template  slot  S,  then  an  instance  of  C  has  an  own  slot  S.  In 
other  words,  each  instance  of  C  has  a  unique  value  of  the  property  denoted  by  S. 

Facets  specify  constraints  on  slots.  OKBC  defines  a  standard  set  of  constraints,  including 
type  (e.g.,  string,  number,  date,  instance,  class)  and  cardinality.  OKBC  also  allows  on¬ 
tologies  to  extend  the  set  of  facets  attached  to  a  slot. 

An  OKBC  ontology  is  a  set  of  slots,  classes,  and  facets.4  An  ontology  defines  concepts 
but  does  not  identify  concrete  instances.  An  ontology  plus  a  set  of  instances  of  the  classes 
in  the  ontology  is  termed  a  knowledge  base.  An  ontology  provides  a  framework  for  rea¬ 
soning;  a  knowledge  base  allows  reasoning  about  specific  data.  The  distinction  is  analo¬ 
gous  to  the  difference  between  an  IDEF1X  specification  of  a  physical  database  and  a  data 
set  structured  according  to  that  specification. 

3.2.3  Representing  the  GH  Using  Frames 

The  following  is  a  description  of  the  general  approach  IDA  used  to  translate  the  GH  into 
a  frame-based  representation  of  an  ontology.5  Figure  6  illustrates  the  concepts  for  the 
translation  of  the  three  GH  entities  OBJECT-ITEM,  OBJECT-ITEM-ASSOCIATION,  and 
ORGANISATION. 

1.  Each  GH  entity  was  modeled  as  a  class  in  the  GH  ontology.  Each  class  had  an 
own  slot  to  denote  the  class’  name,  taken  from  that  of  the  entity.  Because  of  con¬ 
siderations  of  implementing  the  ontology  in  programming  languages,  IDA 


The  GH  naming  convention  of  prefixing  entity  names  to  attributes  deliberately  avoids  misleading  read¬ 
ers  into  such  thinking. 

4  The  OKBC  standard  gives  implementers  considerable  freedom.  What  actually  constitutes  an  ontology 
is  more  than  this  sentence  implies. 

5  This  ontology  is  referred  to  in  this  report  as  “the  GH  ontology.”  The  phrase  “the  GH”  refers  to  the  GH 
IEDM. 
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GH5  Representation 


OBJECT-ITEM-ASSOCIATION 


Figure  6.  Translation  from  ER  Model  to  Frame  Model 

adapted  the  GH’s  naming  conventions.  The  hyphens  were  eliminated,  and  the  up¬ 
percase  names  were  changed  to  initial  capitals.  Thus  entity  OBJECT-ITEM  became 
Objectltem.  An  own  slot  was  also  used  to  provide  documentation  on  each  class. 
The  documentation  was  copied  verbatim  from  the  GH  description  of  the  entity. 

Entity  subtype/super  type  relationships  in  the  GH  were  converted  to  class  sub¬ 
type/super  type  relationships  in  the  GH  ontology.  Class  Objectltem  has  subclasses 
Facility,  Feature,  etc.  IDA  did  not  encounter  any  situations  in  which  multiple  in¬ 
heritances  were  desirable. 

Occasionally,  IDA  identified  sets  of  classes  that  were  related  but  whose  corre¬ 
sponding  entities  in  the  GH  did  not  share  a  super  type.  IDA  grouped  these  classes 
under  a  common  super  class.  Classes  MaterielTypeEstablishment  and 
OrganisationType-Establishment,  for  example,  have  the  super  class 
ObjectTypeEstablishment  in  the  GH  ontology. 

2.  Each  organic  GH  attribute  was  modeled  as  a  template  slot  in  the  GH  ontology. 
Each  slot  had  a  facet  to  denote  the  slot’s  name,  taken  from  the  name  of  the  attrib¬ 
ute.  As  with  classes,  naming  conventions  were  adapted:  the  prefixed  entity  name 
was  dropped,  hyphens  were  dropped,  and  words  other  than  the  first  were  capital¬ 
ized.  So  airfield-hanger-area-quantity  became  hangerAreaQuantity.  (Many  naming 
conflicts  resulted,  especially  with  attributes  whose  names  translated  to  “name”, 
but  the  tool  IDA  used  to  implement  the  ontology  could  handle  those  conflicts.) 

The  slot  has  a  facet  specifying  cardinality  of  1 .  The  GH  specifies  which  attributes 
are  mandatory  and  which  are  optional  in  the  GH  ontology;  a  Boolean  required 
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facet  was  used  to  express  this  information.  A  facet  for  recording  documentation 
was  also  used;  the  documentation  was  taken  directly  from  the  attribute. 

3.  Each  GH  attribute  that  is  a  foreign  key,  and  therefore  implements  a  relationship, 
was  modeled  in  the  GH  ontology  as  a  template  slot  in  the  class  derived  from  the 
entity  of  which  the  attribute  was  a  foreign  key.  The  cardinality  facet  of  the  slot 
specifies  that  the  slot  can  have  multiple  values,  with  no  inherent  upper  limit.  The 
facet  denoting  the  slot’s  name  is  formed  from  the  name  of  the  relationship  in  the 
GH.  The  value  type  of  the  slot  is  “Instance”;  in  other  words,  the  value  of  the  slot 
is  an  instance  of  a  class.  When  the  value  type  is  “Instance”,  one  also  specifies  the 
set  of  classes  of  which  an  instance  must  be  a  member.  For  these  slots,  the  set  is 
the  class  derived  from  the  entity  containing  the  foreign  key  attribute.  For  example, 
the  attribute  object-item-id  of  GH  entity  HOLDING  was  represented  in  the  GH  ontol¬ 
ogy  as  slot  has-Holding,  which  was  attached  to  class  Objectltem.  The  value  of  slot 
has-Holding  is  a  set  of  instances  of  class  Holding. 

3.2.4  Modeling  Type  Equivalence 

One  business  rule  IDA  desired  to  implement  was  a  specification  of  which  slots  contained 
conceptually  equivalent  values.  Mixing  aircraft-parking-area-quantity  and  lower-frequency- 
quantity  would  not  do,  even  though  the  GH  specifies  that  both  happen  to  be  9-digit  inte¬ 
gers.  The  ontology  should  clearly  identify  the  domains  as  different. 

The  problem  was  solved  as  follows.  All  classes  derived  from  GH  entities  were  made  sub¬ 
classes  of  class  Land  C4I  Entity,  itself  a  subclass  of:  THING.  IDA  then  created  another  sub¬ 
class  of:  THING,  called  Type.  Class  Type  groups  the  domains  of  GH  attributes  into  repre¬ 
sentational  hierarchies;  e.g.,  Enumerated-Type,  Numeric-Type,  and  String-Type. 

Every  slot  in  an  OKBC  ontology  has  a  facet  specifying  its  value  type.  In  the  GH  ontol¬ 
ogy,  the  value  type  of  each  template  slot  derived  from  an  organic  attribute  is  “Instance”; 
the  instance  must  be  an  instance  of  Type.  That  two  slots  that  model  the  same  concept  can 
be  specified  by  having  their  value  type  be  restricted  to  the  same  subclass  of  Type.  For  ex¬ 
ample,  class  EquipmentType  has  template  slots  loadedWeightQuantity  and 
unloadedWeightQuantity,  both  of  which  model  weight  in  kilograms.  Consequently,  both 
these  slots  are  restricted  to  instances  of  class  Weight-Quantity  as  their  value  type.  Figure  7 
depicts  these  relationships.  It  shows  part  of  the  class  hierarchy  of  the  GH  ontology;  thin 
lines  show  subclass  relationships.  Two  templates  slots  of  class  EquipmentType  are  shown, 
and,  as  indicated  by  the  arrows,  these  slots’  values  are  both  instances  of  class  Weight- 
Quantity.  Class  Weight-Quantity  has  own  slots  that  specify  significant  digits,  precision,  and 
minimum  value  for  any  instance. 

Class  Type  has  a  template  slot  type-instance-value.  This  slot  is  used  to  store  the  actual  value 
of  an  instance  of  the  type.  In  other  words,  when  an  instance  of  EquipmentType  is  created  in 
a  knowledge  base,  the  instance  has  own  slots  loadedWeightQuantity  and 
unloadedWeightQuantity.  The  value  of  these  slots  is  an  instance  of  Weight-Quantity,  a  sub¬ 
class  of  Type.  Classes  inherit  template  slots  from  super  classes,  and  template  slots  of 
classes  become  own  slots  of  instances,  so  each  instance  of  Weight-Quantity  has  an  own  slot 


17 


:THING 


Land  C4I  Entity 

! _  I _ 

Action  Objectltem  ObjectType 


MaterielType 


EquipmentType 
loadedWeightQuantity 
unloadedWeightQuantity 

AircraftType 


Enumerated-Type  Numeric-Type  String-Type 


Integral-Type  Real-Type 


Weight-Quantity 
digits:  12 
precision:  3 
minimum:  0.0 


Figure  7.  An  Illustration  of  the  Type  Hierarchy 

type-instance-value.  This  own  slot  receives  the  actual  value,  i.e.,  a  number  denoting  a 
weight. 


3.2.5  Modeling  Measurable  Things 

The  properties  specified  so  far  for  Weight-Quantity  only  constrain  its  representation.  Aside 
from  its  name,  nothing  about  Weight-Quantity  suggests  that  it  models  weight,  nor  is  there 
anything  in  the  ontology  to  indicate  what  weight  is.  Inferencing  requires  that  this  infor¬ 
mation  be  present. 

GH  attributes  that  model  weight  are  modeling  a  measurable  property  of  a  physical  entity. 
A  study  of  the  GH  reveals  many  attributes  that  model  measurable  properties.  Not  all  at¬ 
tributes  that  denote  a  measurement  model  physical  properties.  For  example,  attribute 
action-task-status-completion-fraction  models  the  degree  to  which  an  action  is  completed  as  a 
floating-point  value  between  0  and  1.  Also,  some  attributes  that  denote  a  measurement 
are  represented  non-numerically  in  the  GH  with  a  fixed  set  of  codes.  An  example  is 
action-task-priority-code,  which  denotes  “the  rank  of  a  specific  ACTION-TASK  in  the  view  of 
the  planning  organization.”  Its  values  are  the  codes  1,  2,  3,  4,  and  5  -  which,  of  course, 
could  have  been  represented  equally  well  as  integers.  A  better  example  is  reporting-data- 
credibility-code,  whose  valid  codes  are  A,  B,  C,  D,  E,  and  F.  These  values  measure  level  of 
credibility  of  reporting  data. 

An  ontology  based  on  the  GH  should  exploit  this  concept  of  measurability.  IDA  therefore 
added  to  the  GH  ontology  a  class  named  Measurable-Thing.  An  instance  of  Measurable- 
Thing  denotes  some  measurable  characteristic.  An  application  can  search  the  ontology  to 
find  things  the  GH  measures.  Any  two  instances  of  Measurable-Thing  are  distinct  and 
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should  be  considered  different.  The  GH  ontology  contains  instances  that  denote  the  con¬ 
cepts  of  length,  width,  and  area. 

Of  course,  measurable  properties  have  relationships.  Length  times  width  equals  area.  Any 
instance  of  EquipmentType  has  length  and  width  slots;  therefore,  it  should  be  possible  to 
determine  whether  that  EquipmentType  can  fit  in  an  area  specified  by  some  other  GH  slot. 
To  support  this  inference  requires  knowledge  of  the  relationship  between  length,  width, 
and  area.  IDA  therefore  added  to  the  ontology  a  Measurable-Thing-Mapping  class.  An  in¬ 
stance  of  this  class  specifies  a  relationship: 

(Measurable-Thing-Mapping  {Measurable-Thing  ...}  expression  Measurable-Thing) 

In  other  words,  there  exists  a  mapping,  defined  by  some  expression,  from  a  set  of  measur¬ 
able  things  to  a  measurable  thing. 

The  expression  must  be  a  numerical  formula  that  can  accommodate  expressions  such 
as  length  x  width  =  area.  The  GH  ontology  supports  this  through  a  class  hierarchy  shown 
in  Figure  8.  Class  Numeric-Expression,  the  root  of  expressions,  is  used  throughout  the  on¬ 
tology  to  model  numeric  values;  specifically,  the  value  of  slot  type-instance-value  is  an  in¬ 
stance  of  Numeric-Expression  for  any  subclass  of  Numeric-Type.  An  instance  of  Numeric- 
Expression  is  an  algebraic  formula,  a  degenerate  case  of  which  is  a  simple  Integer-Literal  or 
Real-Literal.  A  more  interesting  case  is  the  formula  to  multiply  length  times  width,  which 
is  expressed  as  an  instance  of  class  Product.  This  class  has  a  template  slot  operands,  the 
value  type  of  which  is  a  set  of  Numeric-Expression  instances.  The  operands  of  the  expres¬ 
sion  are  length  and  width,  which  are  expressed  as  instances  of  Measurable-Thing.  The  ex¬ 
pression  that  multiplies  length  and  width  is  therefore  something  like  the  following: 

(Product  {(Variable  (Measurable-Thing  length))  (Variable  (Measurable-Thing  width))}) 

Drawing  inferences  about  related  physical  properties  requires  knowledge  of  their  units  of 
measurement.  The  GH  ontology  has  a  Unit-of-Measurement  class  with  template  slots  that 
model  the  unit’s  name  (e.g.,  meter),  common  symbols  (“m”),  and  concept  modeled  (dis¬ 
tance),  plus  special  template  slots  for  such  sometimes-necessary  properties  as  minimum 
and  maximum  values.  The  GH  ontology  also  has  a  class  Unit-of-Measurement-Mapping  that, 
analogous  to  Measurable-Thing-Mapping,  can  be  used  to  specify  interrelationships  among 
units.  The  class  is  the  root  of  a  hierarchy  that  reflects  the  many  different  kinds  of  map¬ 
pings  that  exist  between  units  (see  Figure  9).  The  three  classes  of  mappings  currently  rec¬ 
ognized  are  multiplicative  (e.g.,  kilogram  x  1000  =  gram),  additive  (“Kelvin  +  273  =  “Cel¬ 
sius),  and  complex  ( (“Fahrenheit  -  32) x  5  /  9  =  “Celsius). 
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Figure  8.  Numeric  Expression  Class  Hierarchy 
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Figure  9.  Unit  of  Measurement  Mapping  Hierarchy 

Some  units  of  measurement  are  composites  of  other  units.  Kilometers  per  hour,  for  in¬ 
stance,  is  a  composite  of  kilometers  and  hours.  Such  units  are  modeled  as  instances  of 
class  Composite-Unit-of-Measurement.  A  template  slot  of  Composite-Unit-of-Measurement 
specifies  the  composite  units.  An  instance  of  the  Many-to-One  class  specifies  a  mapping 
between  a  set  of  units  of  measurement  and  a  single  composite  unit  of  measurement.  The 
ontology  has  an  instance  of  Composite-Unit-of-Measurement  that  denotes  speed  in  kilome¬ 
ters  per  hour.  An  instance  of  Many-to-One  specifies  the  knowledge  needed  to  combine  a 
distance  in  kilometers  and  duration  in  hours  to  obtain  speed  in  kilometers  per  hour.  Other 
instances  of  Unit-of-Measurement-Mapping  specify  how  to  convert  distances  to  kilometers 
and  durations  to  hours.  The  GH  allows  capabilities  to  be  expressed  in  many  different  met¬ 
ric  and  English  units,  but  the  GH  ontology  contains  the  infonnation  necessary  to  convert 
between  them. 
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3.2.6  Modeling  Order 

Some  of  the  GH  data  elements  expressed  as  codes  have  an  implied  ordering.  Examples  of 
such  elements  are: 

•  The  action-task-priority-code  attribute,  whose  legal  values  are  codes  1,  2,  3,  4,  and  5. 
A  value  of  1  denotes  an  ACTION-TASK  of  higher  priority  than  2. 

•  The  ammunition-type-calibre-code  attribute,  whose  legal  values  include  0338,  045, 
and  50. 

•  The  network-security-classification-code  attribute,  whose  legal  values  are  CTS 
(COSMIC  top  secret)  NC  (NATO  confidential),  NR  (NATO  restricted),  NS  (NATO 
secret),  and  NU  (NATO  unclassified). 

•  The  unit-type-size-code  attribute,  whose  legal  values  include  ARMY,  FLEET,  FLIGHT, 
and  SQUAD. 

Each  of  these  domains  introduces  an  ontological  challenge.  The  ordering  in  action-task- 
priority-code  is  intuitively  understood  by  humans,  but  opaque  to  an  application  not  specifi¬ 
cally  programmed  for  it.  The  GH  represents  code  values  as  strings,  not  numbers,  and 
there  is  no  good  reason  to  believe  an  arbitrary  set  of  strings  has  an  inherent  order,  even 
though  an  ASCII  sorting  the  values  for  action-task-priority-code  happens  to  yield  the  correct 
ordering.  The  values  for  ammunition-type-calibre-code  also  sort  in  size  order  from  smallest 
to  largest,  a  result  of  careful  naming  on  the  part  of  GH’s  designers.  Note,  however,  that 
the  smallest  value  of  ammunition-type-calibre-code  represents  the  minimum  ammunition 
size,  whereas  the  smallest  value  of  action-task-priority-code  represents  the  maximum  prior¬ 
ity.  The  first  element  of  the  natural  ordering  of  a  GH  coded  domain  is  not  necessarily  the 
least. 

A  lexicographic  sort  of  a  GH  coded  domain  does  not  always  yield  a  meaningful  ordering. 
The  values  for  network-security-classification-code  do  not  adhere  to  the  usual  spectrum  of 
security  classifications. 

Furthermore,  some  coded  domains  have  a  partial,  not  a  total,  order.  An  ARMY  is  larger 
than  a  SQUAD  but  has  no  relationship  to  a  FLEET  or  a  FLIGHT. 

The  C2  ontology  developed  by  IDA  addresses  these  concerns  by  introducing  an 
OrderSpecification  class  into  the  ontology.  OrderSpecification  has  three  template  slots.  Two 
model  instances  of  a  class.  The  third  describes  an  ordering  relationship  between  them.  An 
instance  may  be  denoted  as  less  than,  less  than  or  equal  to,  or  equal  to  another  instance. 

3.3  Creating  a  C2  Ontology 

The  GH  models  individual  entities,  such  as  actions  and  types  of  materiel,  relevant  to  C2. 
The  GH  ontology  IDA  has  created  is  an  adaptation  of  the  GH5.  It  is  still  not  a  complete 
C2  ontology,  because  it  does  not  explicitly  model  all  command  and  control  concepts. 
These  concepts  are  based  on  the  entities  in  the  GH5,  but  are  at  a  higher  level  of  abstrac¬ 
tion.  An  example  would  be  a  threat.  The  concept  of  threat  is  central  to  C2;  a  war  fighter 
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must  understand  threats  he  faces  to  determine  his  course  of  action.  A  C2  ontology  should 
explicitly  include  the  concept  of  threat. 

The  GH  does  not  directly  model  threats.  It  models  the  entities  that  can  pose  threats,  i.e., 
battlefield  objects.  It  also  models  information  about  battlefield  objects  that  can  help  de¬ 
termine  if  a  given  object  poses  a  threat.  For  instance,  the  threat  posed  by  a  unit  could  be 
based  on  the  unit’s  last  known  location,  direction  of  motion,  and  types  of  weapons  held. 
This  is  only  one  definition  of  threat,  of  course,  and  may  not  be  proper  for  a  given  situa¬ 
tion,  but  the  point  is  that  the  GH  possesses  this  infonnation  and  can  help  war  fighters  in 
threat  recognition,  evaluation,  and  response.  (More  precisely,  our  analyses  support  the 
conclusion  that  the  GH  currently  possesses  enough  information  to  help  war  fighters  rec¬ 
ognize,  evaluate,  and  respond  to  a  wide  range  of  threats.  If  experience  with  the  GH  ontol¬ 
ogy  reveals  shortcomings,  IDA  will  propose  extensions  to  the  GH.)  The  IDA  team,  there¬ 
fore,  decided  to  define  C2  ontology  in  terms  of  the  GH  ontology.  However,  C2  ontology 
likely  will  contain  concepts  that  are  not  necessarily  modeled  in  the  GH. 

One  of  the  advantages  of  basing  the  C2  ontology  on  the  concepts  of  the  GH  is  that  C2 
concepts  can  be  defined  in  terms  of  existing  GH  classes,  slots,  and  facets.  There  is  no 
need  to  define  an  ad  hoc  set  of  concepts  specific  to  the  C2  ontology.  Consider  modeling 
of  the  concept  of  “threat”  in  the  C2  ontology.  The  C2  ontology  contains  a  Threat  class. 
The  template  slots  of  this  class  specify  the  battlefield  object  that  is  threatened,  the  battle¬ 
field  object  that  poses  a  threat,  the  time  at  which  the  threat  exists,  and  the  nature  of  the 
threat.  (These  properties  are  illustrative  and  have  not  been  subject  to  expert  review;  they 
are  not  claimed  to  be  complete  or  fully  realistic.)  A  threat  is  defined  in  terms  of  such  GH 
ontology  classes  as: 

•  Objectltem,  to  specify  the  battlefield  objects  that  pose  and  are  subject  to  threats. 

•  ObjectltemStatus,  to  determine  if  a  battlefield  object  is  hostile. 

•  ReportingData,  to  assess  intelligence  on  hostile  battlefield  objects. 

•  ObjectltemLocation  and  Location,  to  determine  if  a  battlefield  object  is  moving  in  a 
direction  that  would  pose  a  threat  to  another  battlefield  object. 

Although  decision  support  applications  will  likely  use  the  more  abstract  classes  of  the  C2 
ontology  rather  than  the  classes  of  the  GH  ontology  directly,  the  fact  that  most,  if  not  all, 
of  the  higher-level  concepts  will  be  built  using  GH  ontology  classes  will  ensure  data  in¬ 
teroperability  with  the  underlying  GH-conformant  data  stores. 

In  other  words,  the  C2  ontology  will  be  a  fonnalization  of  doctrine  couched  in  terms  of 
GH  concepts  and  aimed  at  directly  supporting  decision  makers.  Moreover,  it  will  central¬ 
ize  the  implementation  of  doctrine,  eliminating  the  need  for  individual  applications  to  re¬ 
implement  portions  of  doctrine  over  and  over. 

Figure  10  illustrates  applications  making  use  of  the  C2  ontology,  or  rather  a  knowledge 
base  whose  instances  are  instances  of  classes  from  the  C2  ontology.  That  the  GH  knowl¬ 
edge  base  is  within  the  C2  knowledge  base  reflects  how  C2  concepts  are  defined  in  terms 
of  GH  concepts;  it  also  indicates  that  designers  are  intended  to  think  in  terms  of  C2  rather 
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Other  Systems 


Figure  10.  Scenario  for  C2  Ontology  Use 

than  GH  KB  classes.  The  knowledge  base  is  populated  from  two  sources.  The  primary 
source  is  a  GH  database.  (Arguably,  in  an  environment  where  a  knowledge  base  is  being 
used,  the  knowledge  base  replaces  the  database.  This  may  prove  true,  but  considerable 
research  has  gone  into  optimizing  database  storage  efficiency  and  query  perfonnance;  no 
such  body  of  work  exists  for  knowledge  bases.  IDA’s  working  assumption  is  that  data¬ 
bases  will  continue  to  be  necessary.)  A  tool  in  a  community  of  interest,  here  named  KB 
Updater,  is  responsible  for  populating  the  knowledge  base  and  keeping  it  up  to  date  with 
respect  to  database  updates,  which  themselves  can  come  from  three  sources:  sensors,  lo¬ 
cal  applications,  or  a  network. 

Applications  do  not  access  the  knowledge  base  directly,  but  rather  through  a  fixed  set  of 
tools  that  provide  an  abstraction  of  the  information.  One  of  these  tools  is  an  inference  en¬ 
gine.  The  inference  engine  attempts,  at  the  request  of  other  tools  and  applications,  to  draw 
conclusions  about  the  data  in  the  knowledge  base.  These  conclusions  are  stated  in  terms 
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of  ontological  concepts;  when  the  inference  engine  is  able  to  draw  new  conclusions,  it 
places  them  in  the  knowledge  base.  Consequently  the  inference  engine  is  the  second  way 
in  which  the  knowledge  base  may  be  modified.  For  example,  the  decision  support  appli¬ 
cation  in  Figure  10  might  periodically  request  the  inference  engine  to  conduct  a  threat 
analysis.  The  inference  engine  could  reach  conclusions  such  as  “Unit  A  threatens  unit  B”, 
which  it  would  state  as  an  instance  of  class  Threat.  It  would  place  this  instance  in  the 
knowledge  base,  reflecting  that  the  threat  was  perceived  at  that  time. 

Systems  A  and  B  do  not  directly  update  the  knowledge  base  either,  but  rather  update  the 
database.  The  KB  Updater  tool  has  the  responsibility  to  update  the  knowledge  base.  This  is 
one  possible  scenario  chosen  to  show  the  constituents  of  a  Col  based  on  the  GH,  and 
should  not  be  construed  as  the  only  possible  system  architecture. 

The  other  systems  outside  the  Col  have  access  to  the  knowledge  base  in  much  the  same 
way  as  systems  within  it.  Their  primary  access  should  be  through  an  inference  engine. 
Because  a  Col  cannot  hope  to  predict  all  the  ways  in  which  other  organizations  might 
want  to  use  its  data,  a  separate  KB  Content  Retriever  tool  exists  that  allows  direct  access  to 
the  knowledge  base.  A  vigilant  Col  would  monitor  uses  of  this  tool  and  attempt  to  infer 
how  other  Cols  are  using  the  knowledge  base;  the  Col  would  evolve  the  ontology  based 
on  this  information. 

3.4  Implementing  the  C2  Ontology 

An  ontology  used  in  a  net-centric  environment  must  be  executable,  i.e.,  its  contents  must 
be  interpretable  by  and  accessible  to  computer  applications.  Fortunately,  several  pro¬ 
grams  exist  that  implement  the  OKBC  protocol. 

Owing  to  its  project’s  goals,  IDA  was  able  to  establish  the  following  requirements  an  im¬ 
plementation  of  OKBC  had  to  satisfy: 

•  The  implementation  should  be  freeware.  This  is  an  exploratory  project,  and  IDA 
hopes  to  distribute  its  results  freely.  Software  licenses  complicate  distribution. 

•  The  implementation  should  run  on  multiple,  heterogeneous  platforms.  A  demon¬ 
stration  of  a  net-centric  environment  is  not  very  convincing  if  it’s  run  on  a  single 
computer.  Even  a  limitation  to  Microsoft  Windows  platforms  seems  constraining 
given  certain  movements  in  the  DoD  towards  Linux  (for  example,  see  [Er¬ 
win  2003]).  The  more  diverse  the  environment,  the  better. 

•  The  implementation  should  be  useful  on  knowledge  bases  of  realistic  sizes.  One 
purpose  of  this  project  is  to  determine  whether  today’s  technology  is  sufficiently 
powerful  to  make  use  of  ontologies  in  a  net-centric  environment.  Some  inference 
algorithms  are  notoriously  slow,  especially  on  large  data  sets.  IDA  explored  what 
inference  capabilities  are  practical  and  (ideally)  to  predict  when  the  DoD  can  ex¬ 
pect  to  field  more  powerful  capabilities. 

•  The  implementation  needs  a  well  defined  application  program  interface  (API). 
Actually,  any  implementation  of  OKBC  will  provide  an  API.  The  use  of  OKBC 
was  not  a  given  when  the  project  began,  however,  and  in  any  case  every  ontology 
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tool  IDA  explored  used  frames  in  some  way,  even  if  not  in  complete  conformance 
with  OKBC.  Some  of  these  tools  are  simply  ontology  editors.  Though  they  are 
useful  for  ontology  design  and  presentation,  they  do  not  support  inferencing  or 
even  the  construction  of  inference  engines. 

•  Semi-automated  translation  of  the  GH  into  an  ontology  should  be  possible.  On¬ 
tology  tools  usually  offer  GUI  ontology  and  knowledge  base  editors,  but  the  GH5 
is  large  enough  to  make  manual  entry  of  an  ontology  a  laborious  task.  IDA 
wanted  to  translate  the  GH5  into  the  language  in  which  a  tool  represents  an  ontol¬ 
ogy  using  as  little  effort  as  possible. 

The  World  Wide  Web  has  spurred  considerable  interest  in  tools  and  technologies  for  im¬ 
plementing  ontologies.  Many  of  these  tools  are  web-oriented.  Their  inputs  and  outputs 
are  received  and  sent  using  the  Hypertext  Transfer  Protocol  (HTTP)  (e.g.,  SESAME 
[Karyakof  2002])  or  at  least  using  an  explicit  client/server  model  (e.g.,  Ontolingua  [Far- 
quhar  1997],  Comtec  [Suguri]).  The  deployment  of  ontologies  in  a  net-centric  environ¬ 
ment  ultimately  relies  on  client/server  connections.  It  is  however  irrelevant  in  the  early 
stages  of  a  project  such  as  this  one,  where  the  emphasis  is  on  the  design  and  development 
of  the  ontology  and  associated  inference  capabilities. 

IDA  settled  on  Protege-2000  [Noy  2000]  as  the  tool  to  model  the  ontology.6  Protege-2000 
is  an  open-source  ontology  and  knowledge  base  editor  that  implements  OKBC.  It  is  under 
development  by  Stanford  Medical  Informatics  at  the  Stanford  University  of  Medicine, 
dating  back  (in  very  early  form)  to  1987.  Its  funding  organizations  include  the  Defense 
Advanced  Research  Projects  Agency,  the  National  Cancer  Institute,  the  National  Institute 
of  Standards  and  Technology,  the  National  Library  of  Medicine,  and  the  National  Science 
Foundation.  A  page  on  Protege-2000 ’s  web  site7  lists  (as  of  this  writing)  sixty  ongoing 
projects  around  the  world  making  use  of  Protege-2000,  in  areas  ranging  from  finance  to 
medicine. 

Protege-2000  is  implemented  in  the  Java  programming  language.  Java’s  availability, 
portability,  ease  of  deployment  in  a  net-centric  environment,  and  wide  support  base  en¬ 
hance  Protege-2000 ’s  value  for  this  project.  (Many  ontology  and  inference  tools  are  writ¬ 
ten  in  Lisp,  reflecting  their  origins  in  artificial  intelligence  research  departments.)  Java 
programs  are  not  known  for  speedy  execution,  but  the  flexibility  of  Java  makes  it  advan¬ 
tageous. 

Protege-2000 ’s  creators  have  studied  its  performance  degradation  as  the  number  of 
frames  increases.  They  aver  that  its  perfonnance  does  not  degrade  for  knowledge  bases 
with  up  to  1,000,000  frames.  IDA’s  studies  with  a  sample  GH  data  set  indicate  that  a  sin¬ 
gle,  isolated  knowledge  base  requires  on  the  order  of  20,000  frames  (see  Section  3.5).  It 
is  possible  that  a  knowledge  base  with  access  to  the  GIG  might  contain  orders  of  magni¬ 
tude  more  data,  but  predicting  GIG  size  is  a  risky  venture.  It  is  an  issue  that  merits  both 
further  study  and  close  watch.  In  any  case,  Protege-2000 ’s  creators  believe  they  can  im¬ 
prove  its  performance  on  large  knowledge  bases. 


6  The  Protege-2000  web  site  is  http://  protege.stanford.edu/. 

7  http://protege.stanford.edu/projects.html. 
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One  problem  with  Protege-2000  is  that  it  is  primarily  an  ontology  and  knowledge  base 
editor  and  only  secondarily  an  inferencing  tool.  It  can  be  used  to  create  ontologies;  more 
precisely,  it  can  be  used  to  define  concepts  and  interrelationships  to  the  extent  permitted 
by  a  frame-based  model.  It  can  also  be  used  to  create  instances  of  classes  in  an  ontology, 
that  is,  to  create  a  knowledge  base.  However,  it  is  deliberately  limited  in  certain  important 
respects.  Most  significantly,  its  constraint  checking  capabilities  are  minimal  and  not  en¬ 
forced.  A  Protege-2000  ontology  can  specify  simple  constraints  on  slot  values:  type, 
range  (for  numeric  types),  and  cardinality.  It  cannot  specify  such  useful  constraints  as  the 
maximum  length  or  format  of  a  string.  Protege-2000  lets  ontology  designers  add  con¬ 
straints  like  these,  but  the  constraints  are  not  implicitly  enforced  by  Protege-2000.  In¬ 
stead,  constraints  must  be  enforced  by  applications,  or  through  user  actions  perfonned  as 
part  of  the  methodology  used  to  develop  and  maintain  a  knowledge  base  (this  is  why  IDA 
developed  classes  for  types  and  units  of  measurement,  rather  than  making  them  slot  fac¬ 
ets). 

Furthermore,  Protege-2000  flags  the  entry  of  erroneous  slot  values  but  does  not  prohibit 
them.  A  slot  may  be  marked  as  required,  but  Protege-2000  will  save  a  knowledge  base  in 
which  that  slot  has  no  value.  The  API  does  not  even  indicate  whether  a  value  is  invalid 
for  a  slot  when  the  slot’s  value  is  set,  though  methods  exist  to  test  that  condition.  In  other 
words,  Protege-2000  makes  the  user  (or  application)  responsible  for  the  consistency  and 
correctness  of  a  knowledge  base. 

Protege-2000  offers  a  more  general  constraint  facility  in  the  Protege  Axiom  Language 
(PAL).  PAL  is  intended  for  model  checking  purposes.  It  is  a  variant  of  the  Knowledge 
Interchange  Format  (KIF)  [Genesereth  1992],  a  first-order  predicate  logic  language.  PAL 
may  be  used  both  to  enforce  constraints  beyond  those  specifiable  as  facets,  and  to  per¬ 
form  simple  queries  on  a  knowledge  base.  It  is  explicitly  not  intended  as  a  general- 
purpose  predicate  logic  language  (as  is  KIF).  Again,  Protege-2000 ’s  designers  are  requir¬ 
ing  others  to  supply  inference  capabilities. 

Fortunately,  Protege-2000  was  designed  to  be  extensible.  It  supports  “plug-ins”,  which  is 
Java  packages  that  extend  Protege-2000 ’s  functionality  in  some  integrated  way  -  that  is, 
the  extra  functionality  is  available  to  the  rest  of  Protege-2000.  One  useful  plug-in  is  Al¬ 
gernon,  an  inferencing  capability  adapted  from  an  earlier  Lisp-based  system  [Kui- 
pers  1994]  to  work  with  Protege-2000  knowledge  bases.  Algernon  is  a  very  general- 
purpose  tool,  implementing  forward  and  backward  chaining,  both  staples  of  rule-based 
inferencing.  Moreover,  its  Protege-2000  plug-in  can  access  native  and  user-defined  Java 
functions.  This  provides  the  often-missing  capability  of  procedural  abstraction,  allowing 
Algernon  rules  to  be  stated  concisely  in  comparison  to  PAL. 

In  short,  Protege-2000  is  not  ideal  but  possesses  many  desirable  characteristics  and  can 
be  extended.  One  goal  of  knowledge  base  design  is  to  encapsulate  business  rules.  Pro¬ 
tege-2000  offers  that  capability. 

Figure  1 1  shows  the  Protege-2000  interface  to  the  GH  ontology.  The  application  displays 
the  class  hierarchy  in  a  window  on  the  left.  This  window  contains  the  classes  discussed  in 
Section  3.2,  which  fonn  a  tree  rooted  at:  THING.  The  window  on  the  right  side  shows  the 
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template  slots  of  the  currently  selected  class  (here,  Action).  The  column  headings  in  the 
lower  right  table  -  Name,  Type,  etc.  -  are  facets  associated  with  a  template  slot.  The  val¬ 
ues  in  the  table  are  the  values  of  the  facets.  In  other  words,  Action  has  a  template  slot 
whose  Name  facet  has  the  value  name.  This  slot’s  value  is  an  instance  of  class  Action- 
Name,  which  though  not  shown  in  Figure  1 1  happens  to  be  a  descendent  of  class  Type. 

Protege-2000  has  some  interesting  features  that  merit  mention  with  regard  to  how  they 
influenced  the  GH  ontology’s  design.  The  following  subsections  cover  them. 

3.4.1  Abstract  Classes 

A  Protege-2000  class  may  be  either  abstract  or  concrete.  An  abstract  class  can  have  no 
instances.  Instead,  subclass  of  an  abstract  class  can  have  instances.  This  modeling  tech¬ 
nique,  common  in  object-oriented  languages,  is  used  to  designate  high-level  concepts  that 
must  be  further  specified  before  it  makes  sense  to  create  instances. 

A  Protege-2000  class  that  is  abstract  has  a  green  “A”  to  its  right.  Figure  11  shows  that: 
THING,  SYSTEM-CLASS,  and  Numeric-Expression  (among  others)  are  abstract.  Protege- 
2000 ’s  designers  have  decided  that  a:  THING  is  too  vague  to  instantiate.  Similarly,  IDA 
has  decided  that  a  Numeric-Expression  is  too  vague  to  instantiate.  Some  of  its  subclasses 
from  Figure  8  can  be  instantiated,  however  -  generally  the  leaves  of  the  class  hierarchy 
tree.  The  implication  is  that  one  must  provide  a  certain  amount  of  detail  before  a  numeric 
expression  can  be  stated  unambiguously. 

Despite  the  ontology’s  rearrangement  of  the  GH  into  a  class  hierarchy,  subclasses  of  Land 
C4I  Entity  use  abstract  classes  sparingly.  In  fact  there  is  only  one:  ObjectTypeEstablishment, 
the  super  class  of  MaterielTypeEstablishment  and  OrganisationTypeEstablishment.  The  GH 
does  not  contain  an  OBJECT-TYPE-ESTABLISHMENT  entity,  but  the  IDA  team,  noting  simi¬ 
larities  between  entities  OBJECT-TYPE-ESTABLISHMENT  and  MATERIEL-TYPE- 
ESTABLISHMENT,  opted  to  take  advantage  of  those  similarities  in  the  GH  ontology.  Be¬ 
cause  no  GH  data  set  will  ever  contain  an  instance  of  OBJECT-TYPE-ESTABLISHMENT, 
class  ObjectTypeEstablishment  can  be  abstract. 

Arguably,  other  classes  in  the  GH  ontology  should  be  abstract.  Consider  class  Location 
(see  Figure  12).  By  itself,  an  instance  of  Location  does  not  specify  a  location.  It  only 
specifies  the  subclass  type  (the  categoryCode  slot)  and  a  relationship  to  an 
ObjectltemLocation  instance.  Moreover,  the  GH  entity  from  which  it  is  derived  -  LOCATION 
-  states  that  the  location-category-code  attribute  (from  whence  categoryCode  derives)  is  a 
complete  discriminator  for  subtypes.  In  theory,  then,  all  possible  subclass  of  Location  are 
known,  so  any  instance  can  be  assigned  appropriately. 
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Figure  11.  Protege-2000  User  Interface  to  the  GH  Ontology 


Unfortunately,  GH  doesn’t  require  that  an  instance  of  LOCATION  have  a  corresponding 
instance  of  a  subtype  entity.  A  GH  data  set  containing  an  instance  of  LOCATION  but  no 
matching  instance  of  a  subtype  is  still  valid.  Translating  such  a  data  set  into  the  knowl¬ 
edge  base  is  problematic.  The  instance  can  be  assigned  to  a  subclass  of  Location  -  location- 
category-code  is  a  required  attribute,  so  a  subtype  can  be  inferred  -  but  if  Location  is  ab¬ 
stract,  then  its  subclasses  Geometric-Volume,  Point,  and  Surface  should  be  abstract  too,  as 
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Figure  12.  Location  Hierarchy  in  Protege-2000 

none  of  them  convey  enough  information  to  specify  a  location.  In  other  words,  an  in¬ 
stance  of  LOCATION  doesn’t  have  enough  information  to  identify  a  concrete  subclass  of 
Location. 

Given  this  situation,  if  GH  classes  such  as  Location,  Objectltem,  ObjectType,  etc.,  are  ab¬ 
stract,  there  will  exist  GH  data  sets  that  cannot  be  translated  into  knowledge  bases.  IDA 
has  opted  for  a  GH  ontology  that  can  model  all  GH  data  sets.  The  trade-off  is  that  per¬ 
forming  an  inference  requires  making  additional  tests  in  order  to  ensure  that  an  instance 
is  of  a  class  specific  enough  to  be  useful. 

3.4.2  Inverse  Slots 

Section  3.2.3  described  how  GH  relationships  are  represented  in  the  ontology:  as  multi¬ 
ple-valued  slots  whose  value  types  are  an  instance  of  a  particular  class.  Figure  12  shows 
how  the  relationship  between  LOCATION  and  OBJECT-ITEM-LOCATION  was  translated  into 
template  slot  provides-geometric-definition-for-ObjectltemLocation. 

This  technique  lets  Protege-2000  represent  1:  N  relationships.  It  also  lets  Protege-2000 
represent  M:  N  relationships  -  but  only  if  no  associative  entity  is  involved.  Unfortunately, 
every  M:  N  relationship  in  the  GH  has  an  associative  entity.  When  one  is  using  a  query 
language  such  as  SQL  to  access  a  GH  data  set,  this  isn’t  a  problem.  An  inner  join  gives  a 
succinct  and  efficient  statement  of  the  set  of  all  locations  associated  with  a  battlefield  ob¬ 
ject. 

Drawing  inferences  from  a  Protege-2000  knowledge  base  is  another  matter,  because  PAL 
isn’t  nearly  as  compact,  expressive,  or  efficient  as  SQL.  If  finding  the  locations  of  a  bat¬ 
tlefield  object  required  finding  all  associated  ObjectltemLocation  instances,  then  searching 
all  Location  instances  for  those  whose  provides-geometric-definition-for-ObjectltemLocation  slot 
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matches  one  of  the  ObjectltemLocation  instances,  implementations  of  Protege-2000  infer¬ 
ence  rules  would  be  large  and  unwieldy. 

Protege-2000  provides  a  technology  that  addresses  this  issue.  Two  slots  may  be  declared 
each  others’  inverse.  The  interesting  property  of  inverses  is  that  creating  a  value  for  one 
slot  of  an  inverse  set  automatically  creates  an  appropriate  value  for  the  other  slot.  In  the 
GH  ontology,  ObjectltemLocation  has  a  slot  objJtemJoc-is-associated-with-Location  that  is  the 
inverse  of  provides-geometric-definition-for-ObjectltemLocation.  Each  association  of  a  Location 
with  an  ObjectltemLocation  automatically  fills  in  both  slot  values.  One  can  easily  find  the 
Location  associated  with  an  ObjectltemLocation.  This  solves  the  query  problem. 

IDA  therefore  created  the  GH  ontology  such  that  every  template  slot  modeling  a  1 :  N  re¬ 
lationship  has  an  inverse  slot.  The  name  of  the  inverse  slot  comes  from  the  child-to- 
parent  phrase  of  the  GH.  The  child’s  name  is  prefixed  to  the  slot’s  name  to  avoid  naming 
conflicts,  as  many  GH  entities  are  the  parent  of  relationships  with  the  same  child-to- 
parent  name  (e.g.,  many  entities  are  the  child  of  an  is-referenced-to  REPORTING-DATA  rela¬ 
tionship). 

3.4.3  Metaclasses 

Protege-2000  fully  implements  everything  required  by  the  OKBC  standard.  However, 
OKBC  allows  features  that  Protege-2000 ’s  developers  chose  not  to  provide.  For  example: 

•  OKBC  allows  a  frame  to  be  an  instance  of  multiple  classes.  Protege-2000,  how¬ 
ever,  restricts  a  frame  to  an  instance  of  a  single  class. 

•  In  OKBC,  an  own  slot  can  be  attached  directly  to  any  frame.  In  Protege-2000,  an 
own  slot  attached  to  a  frame  is  always  derived  from  some  template  slot. 

These  decisions  have  consequences  for  ontology  design  in  Protege-2000.  One  conse¬ 
quence  is  that  characteristics  of  a  class  beyond  those  allowed  by  the  default  facets  must 
be  specified  using  a  metaclass.  A  metaclass  is  a  class  that  happens  to  be  a  subtype  of 
class:  STANDARD-CLASS.  An  ontology  developer  may  specify  the  metaclass  of  a  class. 
By  default,  this  metaclass  is:  STANDARD-CLASS,  which  means  that  its  properties  hap¬ 
pen  to  be  exactly  the  template  slots  of:  STANDARD-CLASS.  These  slots  include:  NAME, 
(a  string):  ROLE  (abstract  or  concrete),  and:  DIRECT-TEMPLATE-SLOTS  (the  template 
slots  of  the  class). 

A  subclass  of:  STANDARD-CLASS  inherits  the  slots,  and  may  add  its  own.  When  the  on¬ 
tology  developer  designates  a  class’s  metaclass  as  something  other  than:  STANDARD- 
CLASS,  he  allows  additional  properties  to  be  specified  for  the  class.  These  properties  ap¬ 
ply  to  all  instances  of  the  class. 

Figure  13  shows  some  of  the  metaclasses  used  in  the  GH  ontology.  Metaclasses  are  used 
extensively  to  assign  meaning  to  subclasses  of  Type.  Figure  13  highlights  Textual -Class, 
which  is  used  for  types  that  store  text.  The  Textual-Class  metaclass  has  two  additional 
template  slots  (in  blue)  that  allow  for  specification  of  whether  a  slot’s  value  is  of  fixed  or 
varying  length,  and  of  the  maximum  length  of  a  string  value  for  the  slot.  This  extra  in¬ 
formation  allows  for  capture  of  the  information  about  text-valued  attributes  in  the  GH. 
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Figure  13.  Metaclasses  in  the  GH  Ontology 
3.5  Status  of  the  Implementation 

IDA’s  implementation  of  the  GH  ontology  models  all  elements  of  version  5.2.  Version  6 
of  the  GH  was  released  in  November  2003;  IDA  will  study  the  new  version  to  determine 
when  the  changes  should  be  transferred  to  the  ontology. 

The  C2  ontology  is  still  in  a  rudimentary  form.  IDA’s  goal  is  to  select  a  few  key  C2  con¬ 
cepts  and  implement  them  as  carefully  as  possible  to  test  the  realism  that  an  ontology  can 
offer  but  creating  a  complete  C2  ontology  is  outside  the  scope  of  the  current  task.  To  date 
the  focus  has  been  solely  on  threats.  In  other  words,  the  C2  ontology  consists  of  the  GH 
ontology  plus  a  single  extra  class,  Threat,  with  slots  that  denote  the  threatener,  threatenee, 
reporting  organization,  and  perceived  degree  of  threat.  Currently  only  instances  of 
Organisation  can  be  a  threat  or  be  threatened. 


Some  metrics  may  help  give  a  feel  for  the  size  and  complexity  of  the  C2  ontology.  It  has: 

•  9,482  frames 

•  898  classes 

•  706  slots 

•  7,878  instances  (most  of  which  are  values  from  the  GH  coded  domains) 

These  numbers  do  not  include  the  system-defined  frames  Protege-2000  includes  in  every 
ontology. 
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In  other  words,  the  number  of  frames  is  on  the  order  of  10, 2  orders  of  magnitude  less 
than  that  which  would  cause  degradations  in  Protege-2000 ’s  perfonnance. 


IDA  has  obtained  sample  GH  data  from  a  NATO  exercise.  It  can  be  modeled  using  ap¬ 
proximately  20,000  frames.  This  suggests  that  real  data  sets  are  of  a  size  that  Protege- 
2000  can  manage. 
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4.  Using  the  Ontology  for  Decision  Support 


This  report  documents  how  to  use  the  C2  and  GH  ontologies  in  a  net-centric  environ¬ 
ment.  Net-centric  warfare  gives  decision  makers  access  to  the  wealth  of  information 
available  on  the  GIG.  Of  course,  decision  makers  are  not  expected  to  search  the  GIG 
themselves;  that  would  be  far  too  time-consuming.  Nor  are  applications  supposed  to  push 
arbitrary  and  overwhelming  amounts  of  data  onto  decision  makers. 

Instead,  DoD  envisions  that  local  applications  will  serve  decision  makers  by  continuously 
looking  for,  and  analyzing,  information  the  applications  deem  relevant.  These  applica¬ 
tions  are  known  as  agents.  The  objectives  of  agents  are: 

•  To  reduce  the  need  for  routine  human  operator  intervention.  Currently,  human 
subordinates  must  be  employed  to  access  and  search  the  GIG.  This  is  an  ineffi¬ 
cient  use  of  resources. 

•  To  identify  the  best  data  to  pull  from  the  GIG  for  analysis  and  inspection.  An 
agent  can  be  responsible  for  filtering  data  based  on  selected  criteria.  In  a  C2  sce¬ 
nario,  criteria  would  include  factors  such  as  current  mission,  current  location,  op¬ 
erational  readiness,  and  perceived  threats. 

As  part  of  the  study,  the  IDA  team  investigated  the  components  of  a  canonical  architec¬ 
ture  for  decision  support  in  net-centric  warfare.  The  rest  of  this  section  discusses  that  ar¬ 
chitecture,  and  the  prototype  system  IDA  has  implemented  based  on  the  architecture. 

4.1  Operational  Architecture 

At  least  for  the  short  term  the  operational  architecture  of  a  decision  support  system  in  a 
net-centric  environment  will  not  differ  greatly  from  that  of  current  environments.  The 
significant  distinction  is  that  the  net-centric  environment  requires  fewer  operators.  Where 
once  humans  performed  searches  for  infonnation,  agents  will  search  the  GIG. 

This  difference  likely  leads  to  consolidation  of  information  within  networks.  In  the  cur¬ 
rent  environment,  someone  is  directed  to  conduct  a  search;  when  he  is  finished,  he  may 
report  the  results  of  that  search  directly  -  i.e.,  verbally  -  to  a  decision  maker.  By  doing  so, 
he  is  filtering  information;  therefore,  the  exact  data  presented  to  the  decision  maker  is  not 
recorded.  By  contrast,  in  a  net-centric  environment  an  agent  performs  the  filtering,  and 
can  leave  a  record  of  what  infonnation  was  omitted  and  what  was  presented. 

4.2  System  Architecture 

The  overall  system  architecture  for  decision  support  systems  in  a  net-centric  environment 
will  likely  contain  the  elements  shown  in  Figure  14.  There  will  exist  a  certain  number  of 
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GH-based  databases,  each  operated  independently,  but  each  with  metadata.  These  data¬ 
bases  will  be  fed  by  local  data  feeds  (sensors,  human  intelligence),  by  local  applications 
(decision  support  systems,  combat  support  systems,  etc.),  and  by  updates  from  the  GIG. 

Communication  involving  decision  support  applications  can  take  several  forms.  Applica¬ 
tions  may  communicate  directly  with  other  applications  (decision  support  or  otherwise) 
over  well-defined  local  interfaces.  They  may  communicate  with  known  applications  or 
database  management  systems  via  the  GIG;  these  communications  also  count  as  occur¬ 
ring  through  well-defined  interfaces,  since  the  initiating  application  knows  of  the  queried 
application  in  advance,  expects  it  to  respond  to  predefined  queries,  and  anticipates  the 
format  of  requested  data. 

In  other  words,  nothing  about  net-centricity  precludes  communication  via  today’s  tech¬ 
nology.  Instead,  net-centricity  provides  access  to  more  data  -  specifically,  to  any  database 
that  contains  metadata.  This  access  occurs,  as  Figure  14  shows,  through  agents.  Each 
agent  is  accessing  the  GIG,  looking  for  information  relevant  to  a  decision  maker’s  current 
situation  (which,  presumably,  is  specified  through  a  decision  support  application).  Stan¬ 
dard  protocols  will  exist  to  help  an  agent  locate  and  retrieve  metadata.  Standard  lan¬ 
guages  must  also  exist  that  allow  an  agent  to  interpret  metadata  and  data.  OWL,  the  Web 
Ontology  Language  [OWL  2003],  appears  to  be  the  emerging  standard. 

The  open  question  raised  by  Figure  14  is  the  nature  and  architecture  of  the  agents.  Collec¬ 
tively,  agents  serve  many  different,  and  sometimes  mutually  exclusive,  roles  in  a  net- 
centric  environment: 


34 


•  Some  agents  are  periodic,  continually  searching  for  and  filtering  infonnation  in 
the  belief  that  it  may  be  useful.  Others  are  aperiodic,  initiated  in  response  to 
commands  from  a  user  or  from  another  agent. 

•  Some  agents  pull  infonnation,  on  request  from  a  user.  Others  push  infonnation, 
believing  that  the  information  is  vitally  important  and  must  immediately  be 
brought  to  a  user’s  attention. 

•  Some  agents  search  the  entire  GIG.  Others  confine  themselves  to  a  community  of 
interest. 

•  Some  agents  accept  metadata  to  interpret  their  inputs  or  produce  metadata  so 
other  programs  can  interpret  their  outputs.  Others  communicate  through  well  de¬ 
fined  interfaces. 

In  short,  “agent”  has  no  single  accepted  definition.  It  is  understood  to  be  an  autonomous 
application,  but  beyond  that  vague  description,  which  includes  many  applications  that  are 
not  considered  agents,  there  is  not  much  agreement  on  the  properties  an  agent  possesses. 

In  the  context  of  decision  support  systems  in  a  net-centric  environment,  IDA  has  found 
that  several  types  of  agents  can  be  useful.  The  following  examples  illustrate  how  each  of 
the  above  types  of  agents  might  be  useful  in  decision  support  applications: 

•  Periodic  agents  can  search  the  GIG  for  mission-relevant  infonnation.  For  exam¬ 
ple,  decision  making  is  aided  by  knowledge  of  supply  availability.  Given  knowl¬ 
edge  of  an  organization  and  its  mission,  an  agent  could  periodically  search  for 
supply  locations  near  an  organization.  These  searches  would  be  based  on  organi¬ 
zation  location,  current  status,  and  projected  needs. 

•  Aperiodic  agents  can  be  launched  in  response  to  specific  situations,  such  as  the 
detection  of  a  threat.  A  threat  response  agent  would  use  doctrine-derived  rules  to 
formulate  acceptable  courses  of  action. 

•  An  agent  that  gathers  information  to  aid  in  decision  support  is  pulling  data. 

•  An  agent  that  informs  a  decision  maker  of  a  situation  that  needs  immediate  atten¬ 
tion  is  pushing  data. 

The  canonical  system  architecture  IDA  is  developing  recognizes  that  a  community  of  in¬ 
terest  is  likely  to  need  different  types  of  agents,  all  operating  concurrently. 

The  architecture  developed  to  date  is  in  response  to  the  concepts  in  the  C2  ontology: 
threats  and  operational  readiness.  It  is  shown  in  Figure  15.  This  is  the  system  architecture 
a  single  unit  might  deploy.  Agent-based  decision  support  in  this  architecture  comprises 
the  following  agents: 

•  A  knowledge  base  updater  agent.  This  is  a  periodic  agent  whose  role  is  to  monitor 
a  GH  database  for  changes,  and  to  incorporate  those  changes  into  the  GH  ontol¬ 
ogy- 
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Figure  15.  Agent  System  Architecture 

•  A  threat  perception  agent.  This  is  a  periodic  agent  whose  role  is  to  monitor  the 
knowledge  base  for  battlefield  objects  that,  according  to  doctrinal  rules,  appear  to 
pose  a  threat  to  the  organization  deploying  the  agent. 

•  A  threat  response  agent.  This  is  an  aperiodic  agent,  initiated  by  the  threat  percep¬ 
tion  agent  in  response  to  a  detected  threat.  Its  role  is  to  establish  courses  of  action 
in  response  to  the  threat. 

•  An  operational  readiness  agent.  This  is  a  periodic  agent.  It  monitors  the  knowl¬ 
edge  base  and  formulates  statements  of  operational  readiness  of  the  organization 
that  initiates  it. 


Figure  15  is  a  realization  of  Figure  10.  The  notion  of  a  general  purpose  inference  engine 
has  been  replaced  by  concrete  agents  that  serve  specific  roles.  (These  agents  could  be  im¬ 
plemented  using  inference  engines;  whether  to  do  so  is  a  technical  decision.) 


36 


Unlike  Figure  10,  Figure  15  shows  no  connection  between  agents  and  the  GIG.  On  the 
one  hand,  Figure  15  is  a  simplification  of  the  actual  architecture,  because  the  software 
tools  used  to  implement  the  agents  (see  Section  4.3)  effects  inter-agent  communication, 
such  as  metadata  searches,  using  a  network.  On  the  other  hand,  Figure  15  shows  a  delib¬ 
erate  design  decision:  the  prototype’s  purpose  is  to  demonstrate  that  the  ontology  is  a  use¬ 
ful  encapsulation  of  C2  concepts.  The  prototype  is  not  intended  to  demonstrate  metadata 
search  capabilities.  A  convincing  demonstration  thereof  necessarily  requires  some  inde¬ 
pendence  between  the  ontology  developer  and  the  agent  developer.  Each  should  be  from 
a  different  Col  in  order  to  prove  that  the  ontology  describes  data  sufficiently  deeply  and 
precisely. 

An  agent  does  not  make  decisions.  It  assists  decision  makers  by  providing  them  with  in¬ 
formation.  The  arrows  in  Figure  15  that  lead  from  the  agents  to  the  decision  support  ap¬ 
plication  demonstrate  this  notion.  These  arrows  indicate  information  provided.  The  deci¬ 
sion  maker  will  evaluate  this  information,  make  a  decision,  and  enter  it  into  the  decision 
support  application,  which  will  then  record  it  in  the  GH  database.  The  KB  Updater  agent 
will  eventually  incorporate  the  decision  directly  into  the  knowledge  base. 

For  example,  suppose  the  information  in  the  knowledge  base  causes  the  threat  perception 
agent  to  infer  the  existence  of  a  threat.  The  threat  perception  agent  will  notify  the  deci¬ 
sion  support  application.  The  decision  support  application’s  user  interface  will  signal  the 
threat.  Simultaneously,  the  threat  perception  agent  notifies  the  threat  response  agent, 
which  examines  the  knowledge  base  to  detennine  appropriate  courses  of  action.  After 
doing  so,  it  prioritizes  the  courses  of  action  and  notifies  the  decision  support  application. 
The  decision  support  application  presents  the  courses  of  action  to  the  decision  makers. 
Each  course  of  action  is  accompanied  by  a  rationale  that  helps  the  decision  makers  decide 
if  the  threat  response  agent’s  prioritization  is  appropriate.  The  decision  makers  reach  a 
decision  and  enter  it  in  the  decision  support  application,  which  casts  it  into  GH  entities  - 
an  ACTION-TASK,  say  -  and  enters  it  into  the  database.  Later,  the  KB  Updater  incorporates 
a  new  ActionTask  instance  into  the  knowledge  base.  Figure  16  presents  this  infonnation 
precisely  in  the  form  of  a  Unified  Modeling  Language  (UML)  sequence  diagram 
[Booch  1996]. 

This  architecture  is  by  no  means  a  mandate.  Agent-based  systems  are  full  of  design  trade¬ 
offs.  Consider  the  decision  to  make  the  KB  Updater  agent  periodic.  One  can  argue  that 
updating  the  knowledge  base  the  instant  new  data  is  received  yields  the  most  up-to-date 
decision  making  capabilities.  The  ability  to  do  so  depends  in  part  on  whether  the  DBMS 
supports  change  detection  and  some  mechanism  to  influence  external  processes  (i.e., 
something  to  modify  the  knowledge  base);  in  other  words,  periodicity  is  determined 
partly  by  technical  factors. 

4.3  A  Prototype  Implementation 

IDA  has  implemented  a  prototype  system  that  tests  the  ideas  and  architecture  in  this  pa¬ 
per.  The  system  comprises  the  applications  and  data  shown  in  Figure  15:  the  decision 
support  system,  the  agents,  and  the  DBMS,  as  well  as  GH  data  sets  managed  by  a  DBMS 
and  knowledge  bases  managed  by  Protege-2000. 
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Figure  16.  Agent  System  Sequence  Diagram 
The  two  primary  objectives  in  building  the  prototype  were: 


•  To  determine  whether  an  ontology  derived  from  the  GH  is  useful  for  drawing  in¬ 
ferences  about  command  and  control-related  information.  The  ontology  should 
encapsulate  at  least  as  much  data  syntax  and  semantics  as  the  GH  does.  The  proto¬ 
type  must  be  able  to  use  this  metadata  to  access  and  manipulate  a  GH  data  set. 

•  To  explore  the  types  of  metadata  that  should  be  created  for  a  C2  Col.  Ontology 
development  is  effort  intensive.  Empirical  evidence  on  what  metadata  is  useful 
will  help  ontology  developers  devote  resources  to  fruitful  areas. 

4.3.1  Agent  Technologies 

Agents  interoperate.  They  are  expected  to  exchange  information.  Exchanging  information 
requires  an  infrastructure.  A  precondition  to  building  the  prototype  was  to  search  for  ex¬ 
isting  agent  infrastructures,  and  to  choose  one  that  would  minimize  the  implementation 
effort  for  the  prototype  while  providing  a  robust  and  realistic  platfonn. 

IDA  used  an  implementation  of  the  standards  defined  by  the  Foundation  for  Intelligent 
Physical  Agents  (FIPA)  [FIPA2001].8  FIPA,  originally  conceived  for  robotics,  has 
evolved  into  a  comprehensive  set  of  standards  for  agent-based  systems.  The  standards 
cover  such  areas  as: 


FIPA’s  web  site  is  http://www.Fipa.org/. 
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•  Abstract  architecture:  a  general  statement  of  how  agents  can  pass  messages  to 
each  other. 

•  Agent  communication',  a  standard  set  of  communicative  acts  agents  may  perform 
languages  in  which  they  can  perform  the  acts,  and  protocols  for  performing  the 
acts.  FIPA  also  defines  how  to  include  non-standard  acts  and  languages. 

•  Agent  management:  How  an  agent  may  announce  its  presence  on  a  network,  and 
how  an  agent  may  search  for  other  agents. 

•  Agent  message  transport:  How  messages  are  transported  across  networks. 

FIPA’s  web  site  lists  ten  implementations.9  Each  implements  a  selected  set  of  FIPA  stan¬ 
dards.  Some  are  intended  as  general-purpose  agent  development  platforms.  Others  have 
specific  goals  (e.g.,  supporting  web-based  commerce).  IDA  used  the  following  factors  to 
make  a  selection: 

•  Standards  supported.  IDA  focused  on  the  implementations  that  implemented  FIPA 
standards  related  to  ontologies. 

•  Support  for  general-purpose  agent  development.  Some  of  the  implementations 
have  specific  goals  (e.g.,  supporting  web-based  commerce)  that  limit  their  expres¬ 
siveness. 

•  Ability  to  interface  to  Protege-2000  s  API.  Some  of  the  implementations  have 
their  own  language  in  which  to  create  ontologies.  By  the  time  IDA  had  to  select 
an  agent  infrastructure,  much  of  the  C2  ontology  was  already  written.  Re-writing 
the  ontology  in  the  native  language  of  an  agent  infrastructure  was  a  possibility, 
but  none  seemed  as  powerful  as  Protege-2000. 

This  factor  effectively  narrowed  the  search  to  agent  infrastructures  implemented 
in  Java. 

•  Open  source  software  infrastructure.  Agent  technology  is  relatively  new,  so  docu¬ 
mentation  is  poor  and  responsive  support  lacking.  In  such  an  environment,  open 
source  is  the  only  practical  choice. 

IDA  decided  to  use  FIPA-OS  [Poslad  2000]. 10  FIPA-OS  is  probably  the  most  mature  im¬ 
plementation  of  FIPA  standards.  It  was  originally  developed  by  the  telecommunications 
company  Bell  Northern  Research,  and  has  gone  through  ten  major  releases  that  have  in¬ 
corporated  extensions  and  bug  fixes  from  individuals  and  institutions  around  the  world.  It 
has  an  active  user  community,  an  invaluable  resource  to  hasten  the  learning  curve. 

4.3.2  Database  Technologies 

The  implementation  also  required  a  DBMS  to  manage  a  GH  data  set.  IDA  opted  not  to 
purchase  a  commercial  database  server  because  of  the  considerable  expense.  That  left 
three  reasonable  choices:  Microsoft  Access,  MySQL,  and  Oracle’s  Personal  DBMS.  IDA 
eliminated  Microsoft  Access  because  its  limit  on  the  number  of  integrity  constraints  for 


9  http://www.fipa.org/resources/livesvstems.html. 

10  The  home  page  for  FIPA-OS  is  http://fipa-os.sourceforge.net/. 
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an  individual  DB  is  much  lower  than  the  number  of  integrity  constraints  in  the  GH5.  With 
respect  to  MySQL  the  IDA  team  concluded  that  it  was  viable  even  though  its  suite  of  da¬ 
tabase  maintenance  tools  is  less  mature  than  Oracle’s.  IDA  therefore  implemented  the 
prototype  using  both  version  9i  of  Personal  DBMS  and  version  4. 17  of  MySQL. 

4.3.3  XML  Technologies 

Early  in  the  prototype’s  implementation,  it  became  apparent  that  the  Extensible  Markup 
Language  (XML)  [W3C  2000],  the  web’s  de  facto  standard  for  document  exchange, 
would  play  an  important  role.  XML  facilitates  the  transmission  of  entities  as  structured 
information.  To  convert  an  entity  -  an  instance  of  a  Java  class,  for  example  -  into  XML 
requires  a  parser.  IDA  needed  an  implementation  of  a  parser. 

One  seldom  writes  an  XML  parser,  but  instead  uses  an  XML  parser  generator.  These  tools 
take  as  input  a  specification  of  the  structure  of  an  XML  document.  These  specifications 
are  written  in  two  standard  languages.  The  earlier  language,  document  type  definition 
(DTD)  [W3C  2000]  is  less  expressive  than  its  successor,  XML  Schema  (XMLS) 
[W3C  2001],  However,  the  XML  documents  used  in  the  prototype  could  be  adequately 
expressed  as  DTDs,  and  the  expressive  power  of  XMLS  increases  the  complexity  of  the 
generated  parser.  IDA  decided  to  express  XML  document  structure  as  a  DTD. 

IDA  used  the  Zeus  parser  generator.1 1  Zeus  fully  supports  DTDs  defined  by  the  XML  1.0 
specification.  Parsers  produced  by  Zeus  are  100%  Java  code. 

4.3.4  Prototype  Components 

The  prototype  simulates  a  set  of  mutually  friendly  organizations  wanting  to  make  deci¬ 
sions  about  courses  of  action  regarding  threats  from  hostile  organizations.  Each  friendly 
organization  has  access  to  a  DBMS  with  a  GH  data  set.  Organizations  may  share  the 
same  data  set,  but  no  organization  has  direct  access  to  more  than  one  data  set  (but  inter¬ 
agent  messages  provide  indirect  access). 

Each  friendly  organization  has  its  own  C2  knowledge  base.  It  uses  this  knowledge  base  to 
reason  independently  of  other  organizations. 

Each  friendly  organization  has  a  set  of  sensors.  A  sensor  provides  intelligence  about  the 
location  of  hostile  organizations  within  a  fixed  area. 

Each  friendly  organization  runs  a  decision  support  application.  This  application  initiates 
agents  and  accesses  the  GH  database  as  shown  in  Figure  16. 

Characteristics  of  hostile  organizations  are  known  to  friendly  organizations  to  the  extent 
that  they  can  be  described  in  a  GH  data  set.  Currently,  the  important  characteristic  of  a 
hostile  organization  is  its  location  over  time.  A  friendly  organization  calculates  a  hostile 
organization’s  track  from  this  information  and  deduces  whether  it  lies  in  the  hostile  or¬ 
ganization’s  path.  That  is  the  current  definition  of  threat. 


1 1  Zeus  is  available  at  http://zeus.enhydra.org/. 
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These  considerations  led  IDA  to  design  the  system  as  the  components  shown  in  Figure 
17.  (The  figure  shows  three  friendly  organizations  and  three  hostile  organizations,  but  the 
number  of  each  is  a  runtime  parameter.)  Each  friendly  organization  rectangle  represents  a 
unique  application  process,  with  the  components  shown  in  Figure  15. 


With  one  exception,  all  inter-process  communication  occurs  through  agents.  (The  excep¬ 
tion  is  a  friendly  organization’s  communication  with  the  DBMS.  The  mechanism  for 
communication  to  the  DBMS  is  a  decision  of  the  DBMS  vendor.)  Each  agent  knows  the 
types  of  agents  with  which  it  might  profitably  share  data,  and  is  responsible  for  searching 
for  all  agents  of  that  type.  The  agents  use  FIPA-OS  agent  management  tools  to  carry  out 
this  task.  The  threat  perception  agent,  for  instance,  searches  for  all  known  threat  response 
agents.  In  consequence,  whenever  the  threat  perception  agent  of  one  friendly  organization 
detects  a  threat,  the  threat  response  agents  of  all  friendly  organizations  analyze  the  threat 
to  see  if  it  affects  their  mission  in  any  possible  way. 

The  prototype  simulates  zero  or  more  hostile  organizations.  A  hostile  organization  is 
identified  by  name.  Its  characteristics  come  from  the  GH  data  set.  A  hostile  organization 
is  required  to  have  a  location.  As  part  of  executing  the  prototype,  it  may  be  set  in  motion; 
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parameters  of  motion  are  its  speed,  bearing  angle,  and  the  interval  in  seconds  between  the 
time  it  recalculates  its  position.  Figure  18  shows  the  user  interface  a  hostile  organization 
displays. 


Figure  18.  Hostile  Organization  User  Interface 

Hostile  organizations  are  implemented  as  agents.  They  are  not  true  agents,  in  that  they  do 
not  draw  inferences  or  interact  with  a  knowledge  base.  Using  FIPA-OS  agent  technology 
simplifies  the  implementation  of  their  communication  infrastructure. 

An  execution  of  the  prototype  creates  a  single  SimState  application.  This  application, 
which  is  implemented  as  an  agent  (as  with  hostile  organizations,  to  take  advantage  of 
FIPA-OS ’s  communication  utilities),  maintains  ground  truth.  Each  time  an  organization 
changes  position,  it  communicates  its  new  location  to  the  SimState  agent.  (The  hostile 
organization  in  Figure  18  does  so  every  13  seconds.)  Currently,  battlefield  object  location 
is  the  only  ground  truth  the  SimState  agent  maintains.  Sensors  of  friendly  organizations 
get  their  information  by  sending  a  message  to  the  SimState  agent,  asking  for  the  locations 
of  all  battlefield  objects  within  the  range  of  the  sensor. 

4.3.5  The  Data  Set 

To  add  realism,  IDA  used  an  unclassified  data  set  from  a  NATO  exercise  that  occurred  in 
and  around  Fort  Hood,  Texas. 

The  data  set  IDA  received  used  version  4  of  the  GH.  IDA  converted  the  data  set  to  ver¬ 
sion  5. 

Version  5  mainly  extends  version  4,  and  where  possible,  IDA  added  extra  specificity  to 
the  data  set.  For  instance,  Figure  19  shows  that  version  5  has  a  richer  set  of  subtypes  for 
ORGANISATION-TYPE  than  does  version  4.  For  each  UNIT-TYPE  instance,  IDA  added  cor¬ 
responding  GOVERNMENT-ORGANISATION-TYPE  and  MILITARY-ORGANISATION-TYPE  in¬ 
stances. 

Version  4  models  associations  between  battlefield  objects  as  relationships  between  sub- 
types  of  OBJECT-ITEM  including  an  associative  entity  such  as  ORGANISATION-PERSON- 
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GROUP-ORGANISATION-TYPE 
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/ATE-SECTOR-ORGANISATION-TYPE 

GOVERNMENT-ORGANISATION-TYPE 

i 


ix 


ORGAN  ISATION-TYPE  in  GH4  ORGAN  ISATION-TYPE  in  GH5 

Figure  19.  Migration  of  ORGANISATION-TYPE  from  GH4  to  GH5 

ASSOCIATION.  Version  5  uses  a  more  general  scheme:  OBJECT-ITEM  has  subject  and  ob¬ 
ject  relationships  to  associative  entity  OBJECT-ITEM-ASSOCIATION.  IDA  converted  all  bat¬ 
tlefield  object  associations  to  the  version  5  approach. 

Occasionally,  differences  between  the  versions  could  not  be  resolved  by  an  exact  map¬ 
ping.  In  such  cases  IDA  made  an  arbitrary  decision  that  seemed  justifiable  in  the  context 
of  the  prototype.  For  example,  version  4  includes  the  attribute  point-horizontal-precisio- 
code,  which  records  the  precision  to  which  a  POINT  is  measured.  Legal  values  for  this  at¬ 
tribute  are  codes  such  as  “100M”,  meaning  precision  of  100  meters.  Version  5  has  no  ex¬ 
act  matching  attribute.  The  attribute  absolute-point-angular-precision-code  denotes  the  preci¬ 
sion  to  which  an  ABSOLUTE-POINT  is  measured,  but  its  values  state  precision  in  degrees, 
not  meters.  IDA  mapped  point-horizontal-precision-code  to  the  closest  value  in  absolute-point- 
angular-precision-code. 

4.3.6  The  Decision  Support  Application 

The  most  significant  component  of  the  prototype  is  the  decision  support  application.  It  is 
responsible  for  launching  the  agents  that  draw  inferences,  and  for  presenting  a  graphical 
user  interface  demonstrating  that  the  types  of  information  inferred  from  the  knowledge 
base  can  be  useful  in  decision  support. 

IDA’s  objective  for  the  prototype  was  to  demonstrate  how  the  GH  ontology  can  be  used 
to  reason  about  C2-related  issues.  Figure  20  shows  the  interface.  The  screen  is  divided 
into  the  following  areas: 
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•  Map :  The  area  in  the  upper  left  displays  unit  locations  atop  a  topographic  map.  A 
unit  is  designated  by  a  “U”.  Friendly  units  are  shown  raised,  in  blue.  Hostile  units 
are  shown  lowered,  in  red.  The  organization  running  the  decision  support  applica¬ 
tion  (here,  Panzerbataillon  433)  has  a  cyan-colored  “U”. 

The  topographic  map  comes  from  TopoZone.com,  a  commercial  web  site  that  dis¬ 
tributes  United  States  Geographical  Survey  maps.  IDA  eschewed  military  maps  to 
ensure  that  the  prototype  contained  no  classified  information. 

•  Organization  Holdings :  The  table  in  the  lower  left  displays  personnel  and  materiel 
possessed  by  the  organization  running  the  decision  support  application.  More  pre¬ 
cisely,  the  table  displays  the  name  of  each  OBJECT-TYPE  instance  associated  with 
an  organization  through  an  instance  of  HOLDING,  along  with  the  value  of  the 
holding-operational-quantity  attribute.  The  values  are  refreshed  as  the  organization 
consumes  and  obtains  materiel  (though  the  prototype  currently  does  not  include  a 
consumption  model).  The  values  come  from  the  knowledge  base,  not  the  data¬ 
base,  and  therefore  reflect  ongoing  reasoning. 

•  C4I  Display.  The  box  in  the  lower  right  corner  shows  two  items  relevant  to  C4I. 
The  top  item  is  the  organization’s  current  task.  When  the  application  starts,  this 
task  is  obtained  from  the  database.  It  is  refreshed  as  the  organization  makes  deci¬ 
sions  or  receives  orders. 

The  lower  item  shows  updates  to  the  knowledge  base.  These  are  either  generated 
by  the  decision  support  application,  or  received  from  other  applications  through 
the  underlying  GH  database. 

•  Threats'.  The  box  on  the  right  side  shows  the  threats  currently  known  to  the  or¬ 
ganization.  In  Figure  20,  there  is  one  threat,  named  30  Armor  Recce  Coy,  which 
happens  to  be  the  red  organization  (in  the  prototype,  if  the  user  moves  the  cursor 
over  a  “U”;  a  pop-up  displays  the  unit’s  name).  The  threat  perception  agent  has 
detected  that  30  Armor  Recce  Coy  is  moving  and  that  Panzerbataillon  433  is  in  its 
path.  Decision  makers  must  act. 

When  the  threat  perception  agent  detects  a  threat,  it  notifies  all  threat  response  agents. 
Each  threat  response  agent  examines  the  knowledge  base  to  determine  possible  courses  of 
action.  The  threat  response  agent  for  Panzerbataillon  433  formulates  courses  of  action  and 
gives  them  to  the  decision  support  application,  which  then  displays  them  to  the  user  as 
shown  in  Figure  2 1 . 

In  any  given  situation,  doctrine  dictates  the  courses  of  action.  The  threat  response  agent 
has  identified  four.  Each  is  assigned  a  rating,  which  is  a  value  from  0.0  to  1.0  that  priori¬ 
tizes  the  courses  of  action.  If  the  rating  is  0.0,  it  is  not  shown  unless  the  user  selects  the 
Show  Impossible  Courses  of  Action  checkbox.  The  two  viable  courses  of  action  are  that  the 
organization  defend  its  position  or  withdraw.  The  threat  response  agent  uses  knowledge 
of  the  threat’s  holdings  and  its  own  holdings  to  compute  the  rating. 
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Figure  20.  The  Decision  Support  Application  User  Interface 


The  decision  maker  is  unlikely  to  accept  the  threat  response  agent’s  prioritization  without 
obtaining  more  information.  Clicking  the  View  button  for  a  course  of  action  supplies  de¬ 
tails  on  how  the  agent  reached  its  conclusion.  Figure  22  shows  the  details  for  the  top- 
rated  course  of  action  in  Figure  21.  It  provides  a  simple  but  logical  set  of  reasons  for  the 
rating.  In  a  real  system,  the  decision  maker  would  want  more  details  on  each  step  -  e.g., 
how  “adequate”  are  the  supplies?  -  but  for  the  prototype  the  infonnation  in  Figure  22 
makes  the  point. 

The  decision  maker  may  select  a  course  of  action  from  the  given  set.  When  he  does,  the 
decision  support  application  phrases  this  course  of  action  as  a  set  of  GH  entities:  an 
ACTION-TASK,  an  ORGANISATION-ACTION-ASSOCIATION,  ACTION-RESOURCE  instances, 
etc.  These  entities  are  added  to  the  GH  database,  from  whence  they  are  propagated  to 
other  GH  databases  and  eventually  added  to  the  knowledge  base  of  each  active  decision 
support  application. 
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Land  C4I0S5S8:  Threat  Response  Courses  of  Action 
"3C  Armor  Recce  Coy"  is  threatening  "Pamerbataillon  433" 
Courses  of  Action  (2  of  4) 


Rating 

Course  of  Action 

1! 

0.984 

We  formulate  a  DEFEND  action  in  response  to  the  thr... 

View 

0.016 

We  request  permission  to  withdraw  from  our  location  i... 

View 

Figure  21.  Example  Courses  of  Action 


t Course  of  Action  Rationale 


2<J 

We  formulate  a  DEFEND  action  in  response  to  the  threat. 
Rationale 

We  are  threatened. 

We  are  not  otherwise  tasked. 

Our  supplies  are  adequate  for  defense  against  the  threat. 


OK 


Figure  22.  Example  Justification  for  Course  of  Action 


4.3.7  Implementing  Inferencing 

Reasoning  about  C2  using  the  knowledge  base  is  a  central  function  of  the  prototype.  Ex¬ 
amples  mentioned  so  far  include: 


•  How  the  threat  perception  agent  detects  that  one  organization  threatens  another. 
Detection  includes  the  important  sub  function  of  filtering  out  false  positives  to 
prevent  information  overload. 

•  How  the  threat  response  agent  determines  the  courses  of  actions  applicable  in  a 
given  situation. 

The  ability  to  express  these  examples  succinctly  will  influence  the  implementation  strate¬ 
gies. 


IDA  considered  several  technologies  for  drawing  inferences  on  Protege-2000  knowledge 
bases.  Two  were  studied  carefully.  The  first  was  PAL,  the  language  developed  as  an  inte¬ 
gral  part  of  Protege-2000.  The  second  was  Algernon,  available  as  a  Protege-2000  plug-in. 


IDA  found  PAL  inadequate.  It  is  verbose,  it  lacks  procedural  abstraction  capabilities,  and 
its  support  for  mathematical  analysis  is  limited  to  simple  arithmetic.  This  last  problem 
means  it  cannot  be  used  to  model  threat  detection,  which  requires  computing  distance 
from  geodetic  coordinates.  IDA  did  create  a  PAL  frame  that  models  whether  an  organiza¬ 
tion  is  hostile  -  a  part  of  threat  detection  -  but  decided  that  PAL’s  minimal  abstraction 
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facilities  resulted  in  inordinately  and  unjustifiably  complicated  expressions  IDA  ulti¬ 
mately  did  not  use  the  frame  in  the  prototype. 

This  criticism  of  PAL  is  unduly  harsh,  for  PAL  is  not  intended  for  general-purpose  rea¬ 
soning.  It  is  better  suited  to  constraint  enforcement.  There  was  little  need  for  constraint 
enforcement  in  the  prototype,  however,  so  IDA  did  not  end  up  using  PAL. 

IDA  found  Algernon  to  be  better.  Algernon  is  suited  to  general-purpose  reasoning.  Fur¬ 
thermore,  it  can  interface  to  system-  and  user-defined  functions  written  in  either  Java  or 
Lisp,  a  feature  that  greatly  enhances  its  practical  application.  The  version  available  at  the 
time  the  prototype  was  being  developed  had  numerous  bugs,  and  though  Algernon’s  au¬ 
thor  was  responsive  to  bug  reports,  IDA  eventually  decided  that  using  Algernon  would 
introduce  delays.  Algernon  was  not  used  for  this  implementation,  but  subsequent  work  at 
IDA  is  actively  pursuing  the  use  of  Algernon. 

IDA  ultimately  implemented  inferencing  in  Java.  Agent  methods  directly  invoke  methods 
in  the  Protege-2000  API.  This  is  acceptable  for  the  specialized  inferencing  performed  in 
the  prototype.  It  is  less  desirable  in  a  real  decision  support  application  because  it  decen¬ 
tralizes  inferencing  rules. 

4.3.8  Metrics 

The  prototype  is  implemented  mainly  in  Java,  or  in  languages  translated  by  parser  gen¬ 
erators  into  Java.  The  current  system  consists  of: 

•  Approximately  18,000  lines  of  non-generated  Java,  including  documentation. 

•  Approximately  2,000  lines  of  other  languages.  These  languages  are: 

•  Document  Type  Definition  (DTD):  specifications  of  XML  documents. 

•  XML  documents,  in  particular  a  specification  of  the  mapping  between  a  GH 
data  set  and  a  GH  knowledge  base. 

•  Javacc,  a  language  for  specifying  parsers  written  in  Java. 
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5.  Conclusions  and  Directions 


This  paper  has  discussed  the  design  and  implementation  of  artifacts  intended  to  evaluate 
the  feasibility  of  using  an  ontology  to  make  C2  data  understandable.  Data  understandabil- 
ity  is  a  necessary  component  of  net-centricity.  Creating  an  ontology  is  not  the  only  task 
needed  to  make  data  understandable.  One  must  also  provide  descriptors  for  the  ontology 
that  will  allow  agents  to  find  the  ontology  on  the  GIG.  However,  an  ontology  is  a  neces¬ 
sary  step. 

The  creation  of  the  ontology  and  implementation  of  the  prototype  has  given  the  IDA  team 
the  opportunity  to  work  with  many  state  of  the  art  tools  in  the  area.  This  section  presents 
the  IDA  team’s  experiences,  reflects  on  what  has  been  accomplished,  and  discusses  what 
remains. 

5.1  The  GH  Ontology 

The  GH  ontology  IDA  has  created  is  structurally  similar  to  the  GH  IEDM.  Each  class  in 
the  GH  IEDM  maps  to  a  class  in  the  GH  ontology  (though  not  vice  versa).  Each  organic 
attribute  and  relationship  in  the  GH  IEDM  maps  to  a  slot  in  a  GH  ontology  class. 

This  similarity  partly  reflects  the  capabilities  offered  by  Protege-2000,  which  are  similar 
to  those  offered  by  IDEF1X.  OKBC  pennits  forms  of  knowledge  modeling  that  Protege- 
2000’s  designers  chose  not  to  implement.  For  instance,  OKBC  permits  N-ary  relation¬ 
ships,  whereas  Protege-2000  allows  only  binary  relationships  (although  facets  can  be 
used  to  model  restricted  ternary  relationships).  An  ontology  is  supposed  to  offer  informa¬ 
tion  on  relationships,  and  the  GH  ontology  does  not  describe  the  M:  N  relationships  that 
exist  between  certain  classes  as  explicitly  as  information  modelers  might  desire. 

The  reasoning  capabilities  that  IDA  has  included  in  the  ontology  have  to  do  with  physical 
and  enumerable  properties.  The  property  a  slot  measures  is  described,  and  inferences  can 
be  made  as  to  whether  two  slots  measure  the  same  property,  or  whether  a  set  of  properties 
can  be  combined  to  yield  another  property  (e.g.,  height  x  length  x  width  =  volume).  This 
kind  of  capability  should  prove  useful  in  certain  C2  situations,  such  as  deciding  the  feasi¬ 
bility  of  shipping  a  given  materiel  type  in  a  given  container. 

IDA  has  not  yet  attempted  to  implement  reasoning  involving  actions  -  or  rather,  no 
frames  in  the  ontology  implement  action-based  reasoning.  A  realistic  demonstration  of 
such  reasoning  is  likely  to  require  a  significant  investment  of  time  and  subject  matter  ex¬ 
pert  advice. 

In  hindsight,  the  choice  of  Protege-2000  as  the  ontology  representation  tool  seems  cor¬ 
rect.  The  deficiencies  in  the  core  implementation  of  Protege-2000  have  been  noted  in  this 
paper,  but  Protege-2000  has  an  active  user  community  that  is  busy  implementing  plug¬ 
ins.  These  plug-ins  support  (and  Protege-2000  is  moving  towards)  the  best  standards  on 
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knowledge  representation  devised  by  the  World  Wide  Web  Consortium  (W3C).  Use  of 
tools  supporting  web  standards  will  make  the  ontology  portable  and  reusable. 

The  GH  ontology  was  implemented  using  a  frame-based  ontology,  as  opposed  to  descrip¬ 
tion-logic  ontology.  Description-logic  ontologies  are  becoming  increasingly  popular. 
They  are  the  basis  for  OWL,  the  Web  Ontology  Language  [OWL  2003],  and  the  ongoing 
Semantic  Web  efforts  centered  around  OWL  [Berners-Lee  2001].  At  the  time  this  project 
began,  automated  support  for  OWL  was  minimal,  and  reasoning  tools  nonexistent.  The 
past  few  years  have  seen  considerable  growth  of  support  for  the  Semantic  Web,  however, 
and  construction  of  prototype  tools  that  use  OWL-based  ontologies  is  now  practical.  It  is 
therefore  reasonable  to  ask  how  this  project,  were  done  over  again,  should  make  use  of 
OWL.  The  answer  appears  to  be  that  metadata  -  the  infonnation  used  for  ontology  dis¬ 
covery  -  should  be  expressed  in  OWL.  Description  logics  are  suited  to  detennining  simi¬ 
larity  between  concepts.  However,  description  logics  are  not  well  suited  to  expressing  the 
kinds  of  queries  that  the  prototype  makes  to  detennine  threats;  for  that  part  of  the  applica¬ 
tion,  the  frame-based  ontology  seems  preferable.  An  OWL  extension  called  Semantic 
Web  Rule  Language  (SWRL)  [SWRL  2004]  has  been  proposed  to  support  rules  in  OWL 
knowledge  bases.  Eventually  SWRL  may  prove  comparable  in  power  to  tools  that  ana¬ 
lyze  frame -based  ontologies,  but  currently  almost  no  tool  support  exists  for  it. 

Time  constraints,  and  a  tight  focus  on  project  objectives,  prevented  IDA  from  exploring 
other  technologies  and  standards  that  are  potentially  useful  and  certainly  relevant.  Tech¬ 
nologies  and  standards  of  which  we  are  aware,  but  did  not  investigate,  include: 

•  The  DoD  Discovery  Metadata  Standard  (DDMS)  that  facilitates  making  data  visi¬ 
ble  [Stenbit  2003].  Creating  DDMS  descriptors  from  the  C2  ontology  will  be  nec¬ 
essary  to  ensuring  that  the  ontology  is  seen  and  used. 

•  The  Resource  Description  Framework  (RDF)  [RDF  1999],  a  W3C  standard  for 
promoting  interoperability.  The  future  of  message  interchange  among  agents  is 
likely  to  involve  RDF. 

•  The  Java  Expert  System  Shell  (JESS),  a  popular  reasoning  engine  [Friedman- 
Hill  1997].  JESS  should  be  investigated  as  an  alternative  to  Algernon  and  PAL. 

5.2  The  C2  Ontology 

The  IDA  team  worked  on  the  C2  ontology  but  did  so  more  to  explore  how  C2  concepts 
might  be  represented  in  terms  of  the  GH  ontology  than  to  create  a  product  that  an  applica¬ 
tion  could  use,  even  in  a  laboratory  setting. 

The  team  did  gain  enough  experience  to  appreciate  what  the  creation  of  a  realistic  C2  on¬ 
tology  would  entail.  Formalizing  the  concept  of  a  threat  would  require  consultation  with, 
and  consensus  of,  subject  matter  experts.  These  experts  would  be  responsible  for  stating 
conditions  under  which  a  battlefield  object  might  reasonably  be  tenned  a  threat.  The  key 
to  formalizing  their  knowledge  would  be  to  ensure  that  their  statements  can  be  expressed 
in  terms  of  GH  concepts.  Any  nontrivial  statement  of  a  threat  is  likely  to  be  highly  com¬ 
plex. 
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5.3  Use  of  Ontologies 


A  few  words  on  the  merits  of  ontologies  are  in  order.  IDA  invested  nontrivial  effort  in 
developing  the  GH  ontology.  In  theory,  an  ontology  provides  no  benefits  over  a  DBMS, 
i.e.,  anything  that  can  be  expressed  in  an  ontology  can  also  be  expressed  in  a  database.  In 
practice,  IDA  observes  the  following: 

•  The  OKBC  frame -based  model  is  more  abstract  than  the  relational  data  model. 
The  GH  ontology  has  fewer  implementation  details  than  the  corresponding  rela¬ 
tional  database.  The  ontology  needs  no  keys,  and  it  substitutes  relation  names  for 
foreign  keys.  The  GH  ontology  is  closer  to  the  ER  version  of  the  GH5  than  the 
database  is.  The  ER  version  being  easier  to  understand,  IDA  claims  the  GH  ontol¬ 
ogy  is  easier  for  application  developers  to  understand  as  well. 

•  A  significant  portion  of  the  effort  in  developing  the  ontology  was  necessary  be¬ 
cause  of  the  ontology’s  experimental  nature.  As  Section  3  indicates,  IDA  studied 
many  design  tradeoffs  in  the  course  of  the  GH  ontology’s  development.  IDA  ex¬ 
pects  that  subsequent  ontologies  would  use  lessons  learned  from  this  project,  and 
that  their  development  time  would  be  less. 

•  Conventional  wisdom  states  that  business  rules  should  be  kept  outside  of  applica¬ 
tions.  Both  ontologies  and  databases  are  appropriate  places  to  store  rules.  SQL 
standardizes  constraint-based  rules  (e.g.,  a  column  may  not  be  empty;  a  column’s 
valid  values  are  drawn  from  a  prespecified  set).  An  ontology  allows  for  con¬ 
straint-based  rules.  It  also  allows  for  knowledge  acquisition  rules  (e.g.,  the  exis¬ 
tence  of  certain  conditions  means  a  threat  object  should  be  created).  SQL  does 
not  offer  knowledge  acquisition  rules.  Many  DBMSs  extend  SQL  to  allow  for 
knowledge  acquisition  (Oracle’s  triggers  and  its  PL/SQL  language  can  achieve  the 
effect),  but  their  use  would  restrict  database  portability.  An  ontology,  then,  offers 
the  advantage  of  freedom  from  using  nonstandard  database  features  (though  cur¬ 
rent  technologies  for  knowledge  acquisition  are  still  immature;  see  Section  5.4). 

5.4  The  Prototype 

IDA  wanted  the  prototype  to  have  realistic  system  architecture  for  a  decision  support  sys¬ 
tem.  For  this  reason,  it  obtains  data  from,  and  updates,  a  database. 

IDA  also  wanted  the  prototype’s  architecture  to  be  viable  in  a  net-centric  environment. 
Work  in  this  area  is  incomplete.  The  prototype  is  viable  insofar  as  creating  an  ontology, 
but  it  does  not  publish  the  ontology  as  it  should,  nor  does  it  perform  searches  for  arbitrary 
ontologies  and  attempt  to  intuit  their  content’s  relevance.  It  searches  specifically  for  C2 
ontologies  and  assumes  that  the  agents  for  those  ontologies  understand  its  protocols.  This, 
however,  may  not  be  too  different  from  how  a  real  agent  would  behave.  As  Section  1 . 1 
pointed  out,  a  decision  support  application  has  to  be  picky  about  conceptual  equivalence. 
In  any  case,  the  agents  are  programmed  to  deal  with  requests  that  aren’t  understood  or 
even  simply  ignored. 

That  the  inferencing  was  implemented  in  Java  is  unfortunate  in  the  sense  that  IDA  has  not 
been  able  to  evaluate  the  feasibility  of  formalizing  C2  knowledge  in  a  very  high  level 
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language  (VHLL).  Whether  switching  to  a  VHLL  is  technically  advisable  is  controver¬ 
sial.  Artificial  intelligence  researchers  have  been  touting  the  benefits  of  expert  systems 
for  two  decades  but  have  yet  to  produce  evidence  that  writing  in  a  VHLL  is  cheaper  or 
yields  more  reliable  systems  than  does  writing  in  a  procedural  language  such  as  Java. 
However,  rules  written  in  a  VHLL  can  be  incorporated  into  an  ontology  (Protege-2000 
offers  this  feature),  centralizing  them  and  thereby  saving  developers  from  potentially  hav¬ 
ing  to  re-implement  them  in  multiple  agents. 
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Annex  A:  Design  of  the  Ontologies 

This  annex  describes  in  depth  the  ontologies  used  in  the  Ontologies  for  Decision  Support 
project.  The  reader  will  understand  the  design  decisions  and  rationale  for  the  ontologies.  The 
discussion  should  prove  useful  to  someone  who  wants  to  extend  IDA’s  efforts,  or  to  someone 
tasked  with  developing  an  ontology  for  another  domain. 

1.  Structure  of  the  Ontologies 

To  aid  in  making  C2  data  understandable,  the  IDA  team  created  two  distinct  ontologies: 

1.  The  GH5  ontology,  which  directly  models  knowledge  from  a  GH5-conformant  data 
set. 

2.  The  C2  ontology,  which  models  higher-level  C2  concepts  in  terms  of  GH  data. 

The  IDA  team  separated  these  ontologies  into  9  distinct  Protege-2000  projects.  Each  Protege- 
2000  project  is  a  distinct  ontology.  Protege-2000  lets  one  project  include  a  set  of  projects 
(circular  references  are  not  permitted).  The  nine  projects  the  IDA  team  created  have  the  in¬ 
clusion  relationships  shown  in  Figure  1. 


C2 

GH 


Types 


Boolean-Expression  Measurable-Things  Enumerable-Thing 


Numeric-Expression 


Figure  1.  Protege-2000  Project  Inclusion  Hierarchy 

The  ontology  was  split  into  separate  projects  to  encourage  the  encapsulation  of  design  deci¬ 
sions  within  individual  projects.  Thus  a  change  in  how  units  of  measurement  are  represented 
is  made  within  a  single  project. 

A  frame-based  ontology  does  not  encapsulate  design  decisions  to  the  same  degree  as  does  an 
object-oriented  programming  language.  Many  classes  of  changes  to  a  project,  such  as  renam¬ 
ing  or  adding  slots,  require  updates  to  projects  that  include  the  modified  project.  Neverthe¬ 
less,  splitting  components  of  the  entire  C2  ontology  across  projects  is  useful  for  some  practi¬ 
cal  reasons: 
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1 .  It  permits  several  individuals  to  work  on  portions  of  an  ontology  simultaneously. 

2.  It  shortens  load  time  for  individual  ontologies.  Protege-2000  requires  a  non-trivial  in¬ 
terval  to  load  the  entire  GH  ontology.  When  one  is  concentrating  on  unit-of- 
measurement  issues,  loading  just  the  Units  (of  Measurement)  ontology  is  much 
quicker  than  loading  the  entire  package. 

3.  It  forces  a  developer  to  concentrate  on  relevant  concerns.  There  is  less  tendency  to  in¬ 
troduce  arbitrary  and  ad  hoc  frames  into  an  ontology  if  one’s  mind  is  focused  on  a 
narrow  concept. 

The  next  several  sections  discuss  each  ontology  in  Figure  1.  The  low-level,  building  block 
ontologies  are  discussed  first. 

2.  The  Numeric  Expression  Ontology 

The  Numeric-Expression  ontology  supports  the  statement  of  numeric  information.  Numeric 
information  may  be  expressed  as: 

•  Literal  values.  Protege-2000  supports  literal  values  but  none  of  the  other  types  of  nu¬ 
meric  information. 

•  Variables.  A  variable  is  a  reference  to  a  frame.  The  frame  is  assumed  to  contain  suffi¬ 
cient  information  to  obtain  a  numeric  value.  It  is  the  responsibility  of  any  ontology 
that  includes  Numeric-Expression  to  define  how  this  infonnation  may  be  obtained. 

•  Unary  operators.  A  unary  operator  is  anything  that,  when  applied  to  an  instance  of  a 
Numeric-Expression,  yields  an  instance  of  a  Numeric-Expression. 

•  Binary  operators.  A  binary  operator  is  anything  that,  when  applied  to  two  Numeric- 
Expression  instances,  yields  an  instance  of  a  Numeric-Expression. 

•  N-ary  operators.  An  n-ary  operator,  when  applied  to  one  or  more  Numeric-Expression 
instances,  yields  an  instance  of  a  Numeric-Expression. 

Figure  2  shows  the  classes  that  fonn  the  Numeric-Expression  ontology.  Classes  for  inner  nodes 
are  abstract,  because  only  for  the  leaf  nodes  is  enough  information  available  to  describe  an 
instance. 

2.1.  Slots 

The  Numeric-Expression  class  has  a  single  string-valued  template  slot  named  description.  When 
a  user  creates  an  instance  of  the  Numeric-Expression  class,  he  should  enter  a  description  of  an 
expression  in  this  slot.  The  forms  of  the  Numeric-Expression  ontology  use  description  as  the 
form  browser  key;  therefore,  this  description  will  identify  the  instance. 

2.1.1.  Slots  of  the  Literal  Class 

The  Literal  class  has  two  template  slots:  value  and  base.  The  value  slot  denotes  the  literal  value 
of  an  instance.  Its  type  facet  is  string,  though  that  facet  must  be  overridden  in  concrete  sub¬ 
classes.1  The  base  slot  denotes  the  expected  numeric  base  of  a  value.  It  is  intended  as  addi¬ 
tional  information  to  be  used  when  the  value  is  converted  to  or  from  a  string  representation. 
Its  default  value  is  10. 


1  Protege-2000  has  an  Any  type  that  is  arguably  more  appropriate  than  string.  However,  the  version  of  Pro¬ 
tege-2000  used  to  develop  the  Numeric-Expression  ontology  did  not  properly  implement  overriding  Any  slots 
in  subclasses.  Protege-2000’s  developers  claim  to  have  fixed  this  in  subsequent  versions. 
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9  ©  Numeric-Expression  A 

9  ©  Literal* 

1  © Integer-Literal 
©  Real-Literal 

9  ©'Variable* 

©  Instance-Variable 
©  Class-Variable 

9  ©  Unary-Operator-Numeric-Expression* 

©  Negation 
©  Grouping 
9  ©' Trigonometric* 

©  Sine 
©  Cosine 
©  Tangent 

9  ©)  Binary-Operator-Numeric-Expression* 

©Modulo 
©  Product 
©  Sum 
©  Difference 
©  Division 

9  ©' N-ary-Operator-Numeric-Expression* 

©  N-ary-Minimum 
©  N-ary- Maxim  urn 

Figure  2.  Classes  of  the  Numeric-Expression  Ontology 

The  Literal  class  currently  has  two  subclasses,  Integer-Literal  and  Real-Literal.  These  model,  re¬ 
spectively,  integer  and  real  numbers  by  overriding  the  type  facet  of  the  value  slot  to  Integer 
and  Float. 

In  the  form  for  the  Literal  class,  the  value  slot  is  used  as  the  browser  key. 

Protege-2000  represents  numbers  using  32-bit  representations.  This  suffices  to  represent 
GH5  integral  and  real  numbers  that  represent  physical  and  conceptual  properties.  It  is  not 
enough  for  GH5  attributes  that  represent  keys,  which  are  as  much  as  18  decimal  digits.  The 
GH  ontology  does  not  represent  keys,  so  the  32-bit  representation  caused  no  problems.  If  a 
GH5  attribute  had  required  more  than  32  bits,  the  simplest  approach  to  modeling  it  in  Pro¬ 
tege-2000  would  have  been  to  create  a  subclass  of  Literal  that  represented  literal  values  as  a 
string;  that,  along  with  the  base  slot,  would  have  allowed  representation  of  larger  or  more 
precise  literals. 

2.1.2.  Slots  of  the  Variable  Class 

The  Variable  class  has  a  template  slot  variable-ref.  Its  subclasses  specialize  this  slot’s  type.  In 
class  Instance-Variable,  the  variable-ref  slot  is  an  instance  of  THING,  i.e.,  to  any  frame.  In  class 
Class-Variable,  the  variable-ref  slot  is  a  subclass  of  THING  (or  THING  itself). 

Class  Instance-Variable  supports  the  creation  of  numeric  expressions  that  are  functions  of  a  set 
of  variables.  Class  Class-Variable  was  originally  intended  to  support  the  creation  of  numeric 
expressions  involving  metadata.  It  is  not  used  in  the  current  version  of  the  GH  ontology. 

2.1.3.  Slots  of  the  Unary-Operator-Numeric-Expression  Class 

The  Unary-Operator-Numeric-Expression  class  has  a  single  template  slot  named  unary-op-value. 
This  slot,  which  is  of  type  Numeric-Expression  instance,  denotes  the  expression  to  which  a 
unary  operator  is  to  be  applied.  The  operator  itself  is  denoted  by  the  subclass  of  Unary- 
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Operator-Numeric-Expression:  Negation,  Grouping  (i.e.,  parenthesizing),  and  assorted  trigonomet¬ 
ric  operators. 

2.1.4.  Slots  of  the  Binary-Operator-Numeric-Expression  Class 

The  Binary-Operator-Numeric-Expression  class  has  two  template  slots:  binary-op-left  and  binary- 
op-right.  These  slots  are  of  type  Numeric-Expression  instance.  As  with  Unary-Operator-Numeric- 
Expression,  the  actual  operator  is  denoted  by  subclass.  The  binary  operators  currently  in¬ 
cluded  in  the  Numeric-Expression  ontology  are  the  arithmetic  operators  and  the  modulo  opera¬ 
tor. 

2.1.5.  Slots  of  the  N-ary  Operator-Numeric- Expression  Class 

The  N-ary  Operator-Numeric-Expression  class  has  a  single  template  slot  named  operands.  This 
slot  has  multiple  cardinality  but  requires  at  least  one  element.  Order  among  the  values  is  not 
significant.  This  approach  is  a  consequence  of  Protege-2000’ s  decision  to  return  the  values  of 
a  multiple-cardinality  slot  as  an  unordered  collection.  Maxima  and  minima  operators  are  im¬ 
plemented  as  subclasses  of  this  class.  At  one  time  addition  and  multiplication  were  sub¬ 
classes  of  this  class,  but  they  were  ultimately  made  binary  operators  to  keep  them  together 
with  subtraction  and  multiplication. 

2.2.  Instances  in  the  Ontology 

The  Numeric-Expression  ontology  has  instances  for  common  literal  values  such  as  0  and  1.  (In¬ 
stances  for  these  values  exist  as  both  integers  and  reals.)  Consolidating  common  values  in  the 
Numeric-Expression  ontology  makes  other  ontologies  less  cluttered. 

2.3.  Use  of  the  Ontology 

Other  ontologies  use  the  Numeric-Expression  ontology  to  form  knowledge  of  numeric  expres¬ 
sions.  Numeric  expressions  are  useful  in  the  following  circumstances: 

•  Expressing  rational  and  irrational  values.  Although  a  quantity  such  as  1/3  or  sin(45) 
can  be  expressed  as  a  literal  to  the  limit  of  Protege-2 000’ s  precision,  expressing  it  as  a 
formula  aids  in  understanding  the  origins  of  the  expression. 

•  Expressing  functions.  The  GH  data  model  lets  capabilities  be  stated  in  many  different 
units  of  measurement.  An  ontology  should  be  able  to  convert  hours  to  minutes,  i.e.,  it 
should  be  able  to  express  the  formula  m  —  h  x  60 . 

Protege-2000  has  no  built-in  capacity  to  evaluate  instances  of  a  class.  Thus  a  Numeric- 
Expression  instance,  even  one  involving  only  constant  values,  has  no  inherent  meaning  to  Pro¬ 
tege-2000.  The  IDA  team  regretted  this  missing  capacity,  as  some  useful  constraints  could 
have  been  stated  using  Numeric-Expression  instances.  Furthermore,  an  application  that  uses  the 
Numeric-Expression  ontology  may  have  to  implement  an  interpreter.  An  alternate  approach 
that  the  IDA  team  did  not  explore  would  be  to  implement  a  Protege-2000  plugin  that  recog¬ 
nizes  the  Numeric-Expression  class.  Queries  in  Protege-2000 ’s  PAL  are  implemented  as  a 
plugin,  so  the  approach  seems  consistent  with  Protege-2000 ’s  design  philosophy. 

3.  The  Boolean  Expression  Ontology 

The  Boolean-Expression  ontology  serves  an  analogous  purpose  to  the  Numeric-Expression  on¬ 
tology.  It  allows  the  statement  of  Boolean  expressions.  These  expressions  can  be  used  to  de¬ 
scribe  conditions  that  are  true  at  some  moment  in  time,  for  example.  Describing  them  as  a 
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complex  formula  with  bound  variables  may  be  more  meaningful  than  using  simple  true  and 
false  values.  Boolean  expressions  may  be: 

•  Negation  (the  not  operator) 

•  Implication  (the  =>  operator) 

•  Numerical  comparisons  (<,  <,  etc.) 

•  Multiple-operand  expressions,  (AND,  OR,  etc.) 

Assuming  all  variables  are  bound,  an  instance  of  class  Boolean-Expression  denotes  either  truth 
or  falsehood. 

Figure  3  shows  the  classes  in  the  Boolean-Expression  ontology.  Classes  for  non-leaf  nodes  are 
abstract,  because  only  leaf  nodes  have  enough  information  to  make  creating  direct  instances 
logical. 

9  c  Boolean-Expression* 

(c)  Boolean-Negation 
c  Boolean-Implication 
9  c  Boolean-Numeric-Comparison A 

(c)  Boolean-Numeric-Equality-Comparison 
(c)  Boolean-Numeric-lnequality-Comparison 
(c)  Boolean-Numeric-LT 
©  Boolean-Numeric-LE 
©  Boolean-Numeric-GT 
©  Boolean-Numeric-GE 
9  ©'  Boolean-Expr-Multiple-Operands* 

©'  Boolean-Conjunction 
©'  Boolean-Disjunction 
©'  Boolean-Exclusive-Or 
©  Boo  lean- Literal 

Figure  3.  Classes  of  the  Boolean-Expression  Ontology 

3.1.  Slots 

The  Boolean-Expression  class  has  a  single  string-valued  template  slot  named  boolean-expr- 
description.2  When  a  user  creates  an  instance  of  the  Boolean-Expression  class,  he  should  enter  a 
description  of  an  expression  in  this  slot.  The  forms  of  the  Boolean-Expression  ontology  use 
boolean-expr-description  as  the  fonn  browser  key;  therefore,  this  description  will  identify  the 
instance. 

3.1.1.  Slots  of  Boolean-Negation 

The  Boolean-Negation  class  has  a  single  template  slot  named  boolean-expr-negation-operand. 
This  slot,  which  is  of  type  Boolean-Expression  instance,  denotes  the  expression  to  which  nega¬ 
tion  is  to  be  applied. 

3.1.2.  Slots  of  Boolean-Implication 

The  Boolean-Implication  class  has  two  template  slots:  implication-premise  and  implication- 
conclusion.  Both  are  of  type  Boolean-Expression  instance.  They  denote  the  premise  and  conclu¬ 
sion,  respectively,  of  an  implication  operation. 


Protege-2000  does  not  permit  two  slots  to  have  the  same  name,  and  description  is  already  used  in  the 
Numeric-Expression  ontology.  Facets  of  description  could  have  been  overridden  for  Boolean-Expression,  but 
that  approach  courts  disaster  should  description  be  modified  in  Numeric-Expression. 
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3.1.3.  Slots  of  Boolean-Numeric-Comparison 

The  abstract  class  Boolean-Numeric-Comparison  has  two  template  slots:  boolean-numeric-left- 
operand  and  boolean-numeric-right-operand.  They  denote  the  left  and  right  operand  to  apply  to  a 
numeric  comparison  operator.  Each  is  an  instance  of  class  Numeric-Expression.  The  actual 
numeric  comparison  operator  is  specified  as  a  subclass  of  Boolean-Numeric-Comparison.  The 
Boolean-Expression  ontology  provides  the  usual  set. 

3.1.4.  Slots  of  Boolean-Expr-Multiple-Operands 

The  abstract  class  Boolean-Expr-Multiple-Operands  has  a  template  slot  named  boolean- 
expression-operands.  This  slot  is  of  multiple  cardinality.  Each  value  is  an  instance  of  Boolean- 
Expression.  At  least  one  instance  is  required.  The  values  of  the  slot  represent  the  operands  to 
be  applied  to  a  Boolean  operator,  which  is  specified  as  a  subclass.  The  order  in  which  the  op¬ 
erands  are  applied  to  the  operator  is  unspecified.  This  approach  is  a  consequence  of  Protege- 
2000’s  decision  to  return  the  values  of  a  multiple-cardinality  slot  as  an  unordered  collection. 

The  Boolean-Expression  ontology  currently  defines  three  multi-expression  operators:  conjunc¬ 
tion,  disjunction,  and  exclusive-or. 

3.1.5.  Slots  of  Boolean-Literal 

The  Boolean-Literal  class  has  a  template  slot  named  boolean-expr-value.  This  Boolean-valued 
slot  denotes  whether  an  instance  denotes  truth  or  falsehood. 

3.2.  Instances  in  the  Ontology 

The  Boolean-Expression  ontology  contains  two  instances.  One  denotes  truth,  the  other  false¬ 
hood.  Their  labels  are  True  and  False,  respectively. 

3.3.  Uses  of  the  Ontology 

The  GH  ontology  makes  extensive  use  of  the  Boolean  ontology.  However,  it  currently  does 
so  only  in  the  simplest  way:  it  uses  instances  of  Boolean-Literal  to  represent  the  many 
true/false  attributes  in  the  GH5.  These  instances  seldom  have  labels  of  True  or  False.  The  GH 
prefers  to  use  YES  and  NO. 

Protege-2000  has  no  built-in  capacity  to  evaluate  instances  of  a  class.  Thus,  as  with  Numeric- 
Expression,  a  Boolean-Expression  instance  has  no  inherent  meaning  to  Protege-2000.  An  appli¬ 
cation  that  uses  the  Boolean-Expression  ontology  may  have  to  implement  an  interpreter,  or  al¬ 
ternately  implement  a  Protege-2000  plugin  that  recognizes  the  Boolean-Expression  class. 

4.  The  Enumerable  Thing  Ontology 

The  Enumerate-Thing  ontology  models  the  concepts  of  things  that  can  be  enumerated.  Enu¬ 
meration  is  distinguished  from  measurement.  Measurement  represents  a  property  of  an  indi¬ 
vidual  thing.  Enumeration  identifies  a  group  of  things  that  are  homogenous  with  respect  to 
some  criterion. 

The  Enumerable-Thing  ontology  contains  a  single  class  named  Enumerable-Thing  that  is  a  sub¬ 
class  of  THING. 

4.1.  Slots 

Class  Enumerable-Thing  has  three  template  slots: 
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1.  Slot  enumerable-thing-reference  is  a  reference  to  the  thing  of  which  instances  are  being 
enumerated.  Its  value  is  any  class  in  the  ontology. 

2.  Slot  enumerable-thing-name  denotes  a  name  for  an  instance  of  Enumerable-Thing.  It  is 
used  as  the  browser  key  for  the  class’s  fonn. 

3.  Slot  enumerable-thing-symbol  is  a  multiple-cardinality  slot  of  strings.  It  may  be  used  to 
record  commonly  used  symbols  and  abbreviations  for  an  enumerable  thing.  (In  prac¬ 
tice,  this  slot  has  not  been  used.) 

4.2.  Uses  of  the  Ontology 

The  Enumerable-Thing  ontology  is  used  in  the  GH  ontology  to  describe  entities  such  as  per¬ 
sons  and  ammunition. 

The  enumerable-thing-reference  slot  refers  to  a  class,  not  to  an  instance.  In  the  GH  ontology, 
class  Person  -  not  an  instance  of  Person  -  is  an  enumerable  thing.  The  intent  is  to  help  an  in- 
ferencing  engine  reason  about  a  knowledge  base  through  properties  of  things  that  accrue 
from  innumerability. 

5.  The  Measurable  Things  Ontology 

The  Measurable-Things  ontology  models  the  physically  and  conceptually  measurable  proper¬ 
ties.  It  models  only  the  properties,  not  the  entities  for  which  properties  can  exist.  Other  on¬ 
tologies  are  able  to  characterize  entities  in  terms  of  their  measurable  properties. 

The  ontology  distinguishes  between  atomic  and  composite  measurable  things.  As  the  names 
imply,  an  atomic  measurable  thing  cannot  be  decomposed,  whereas  a  composite  measurable 
thing  is  composed  of  a  set  of  other  measurable  things. 

The  Measurable-Things  ontology  also  models  mappings  between  measurable  things.  For  ex¬ 
ample,  it  models  measurement  of  length,  width,  and  area,  and  also  models  that  length  times 
width  equals  area. 

Figure  4  shows  the  classes  of  the  Measurable-Thing  ontology.  Both  Measurable-Thing  and 
Measurable-Thing-Mapping  are  subclasses  of  THING.  Composite  measurable  things  are  modeled 
as  a  subtype  of  measurable  things. 

<?  ©  Measurable-Thing 

(£)  Composite-Measurable-Thing 
©  Measurable-Thing-Mapping 
Figure  4.  Classes  of  the  Measurable  Thing  Ontology 

Measurable  things  are  conceptual  and  are  stated  without  units  of  measurement.  Units  of 
measurement  are  expressed  in  another  ontology. 

5.1.  Slots  of  Measurable-Thing 

The  Measurable-Thing  class  has  three  template  slots: 

1.  The  measurable-thing-name  slot  denotes  a  common  name  for  an  instance  of  a  measur¬ 
able  thing.  This  name  is  presumed  to  be  something  that  might  be  used  as  metadata. 

2.  The  measurable-thing-description  slot  denotes  a  textual  description  for  an  instance.  It  is 
not  intended  to  convey  meaning. 
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3.  The  measurable-thing-subtype-of  slot  is  an  instance  of  a  Measurable-Thing.  It  is  not  re¬ 
quired,  but  if  given,  indicates  a  hierarchical  relationship  that  can  be  useful  as  addi¬ 
tional  metadata.  For  example,  time  of  day  is  a  subtype  of  time. 

The  subclass  Composite-Measurable-Thing  contains  an  additional  template  slot  named  measure- 
expr.  This  slot,  which  is  an  instance  of  Numeric-Expression,  expresses  a  functional  relationship 
that  specifies  how  a  set  of  Measurable-Things  composes  some  instance  of  a  Measurable-Thing. 
An  example  is  given  below. 

5.2.  Slots  of  Measurable-Thing-Mapping 

Each  instance  of  the  Measurable-Thing-Mapping  class  specifies  how  an  instance  of 
Measurable-Thing  can  be  described  in  terms  of  a  set  of  Measurable-Thing  instances.  It  uses  the 
following  four  slots: 

1.  The  measurable-thing-label  slot  gives  a  textual  description  of  the  mapping.  It  is  the 
form  browser  key. 

2.  The  from-measurable-things  slot  is  a  multiple-cardinality  slot  of  Measurable-Thing  in¬ 
stances.  At  least  one  instance  is  required.  It  denotes  the  list  of  things  that  are  to  be 
combined  according  to  the  measurable-thing-expr  slot. 

3.  The  measurable-thing-expr  slot  is  an  instance  of  a  Numeric-Expression.  This  expression 
must  include  instances  of  class  Instance-Variable  (see  Section  2.1.2),  each  of  which 
must  be  refer  to  a  value  in  the  from-measurable-things  slot. 

4.  The  to-measurable-thing  slot  is  an  instance  of  Measurable-Thing.  It  denotes  the  thing  that 
results  when  the  from-measurable-things  are  combined  according  to  the  measurable- 
thing-expr. 

The  Measurable-Thing  ontology  also  adds  class  Measurable-Thing-lnstance-Variable  as  a  subclass 
of  Instance-Variable.  Its  purpose  is  to  separate  variables  used  to  reference  measurable  things 
from  other  variables  used  in  other  ontologies.  The  Numeric-Expression  instance  for  the 
measurable-thing-expr  slot  should  reference  instances  from  this  class. 

5.3.  Instances  in  the  Ontology 

The  Measurable-Thing  ontology  includes  instances  of  measurable  things,  and  mappings  be¬ 
tween  them,  that  are  relevant  to  the  GH  ontology.  Some  examples  of  measurable  things  are: 

•  Distance:  an  amount  of  separation  between  two  locations. 

•  Height,  width,  and  length:  Each  of  these  is  a  subtype  of  distance. 

•  Area  and  volume:  These  are  instance  of  Composite-Measurable-Thing.  There  exist  in¬ 
stances  of  class  Measurable-Thing-lnstance-Variable  that  reference  the  Height,  Width, 
and  Length  Measurable-Thing  instances.  Thus  the  measure-expr  slot  of  Area  is  a 
Product  instance  where  the  left  and  right  operands  are  the  Width  and  Length  instances 
of  Measurable-Thing-lnstance-Variable. 

•  Time,  age,  and  time  of  day:  The  second  and  third  are  subtypes  of  the  first. 

An  example  of  a  measurable  thing  mapping  is  the  relationship  between  speed,  time,  and  ac¬ 
celeration.  Speed  and  time  are  instances  of  Measurable-Thing.  Acceleration  is  an  instance  of 
Composite-Measurable-Thing.  There  exists  an  instance  of  Measurable-Thing-Mapping  in  which: 

•  The  from-measurable-things  slot  has  as  its  value  the  two  instances  Speed  and  Time. 

•  The  to-measurable-thing  slot  has  as  its  value  the  instance  Acceleration. 
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•  The  measurable-thing-expr  slot  has  as  its  value  a  Division  instance  in  which  the  left  op¬ 
erand  is  the  instance  of  Measurable-Thing-lnstance-Variable  that  refers  to  Speed,  and  the 
right  operand  is  the  instance  of  Measurable-Thing-lnstance-Variable  that  refers  to  Time. 

5.4.  Uses  of  the  Ontology 

The  Units-of-Measurement  ontology  extends  the  Measurable-Thing  ontology  with  units  of 
measurement  for  each  measurable  thing.  In  other  words,  Measurable-Thing  describes  a  class  of 
concepts  and  their  interrelationships,  whereas  Units  describes  different  ways  to  express  each 
concept. 

There  are  some  constraints  that  should  be  associated  with  this  ontology.  For  example,  in  an 
instance  of  Measurable-Thing-Mapping: 

•  Every  variable  in  the  measurable-thing-expr  slot  must  refer  to  an  instance  of  a 
Measurable-Thing. 

•  The  cardinality  of  the  from-measurable-things  slot  should  equal  the  number  of  instances 
of  Measurable-Thing-lnstance-Variable  in  the  measurable-thing-expr  slot. 

Unfortunately,  these  constraints  cannot  be  stated  in  Protege-2000  (a  recursive  application 
function  is  needed).  The  IDA  team  opted  to  include  constraints  in  the  ontology,  but  stated 
them  in  natural  language. 

6.  The  Partial  Order  Ontology 

The  Partial-Order  ontology  facilitates  the  specification  of  a  partial  (or  total,  as  a  degenerate 
case)  ordering  among  a  set  of  instances.  It  consists  of  a  single  class,  Order-Specification,  that  is 
a  subclass  of  THING. 

6.1.  Slots  of  Order- Specification 

The  Order-Specification  class  has  the  following  slots: 

1.  The  order-spec-description  slot  provides  a  textual  label  for  each  instance.  It  is  used  as 
the  form  browser  key. 

2.  The  order-spec-a  and  order-spec-b  slots  both  have  instances  of  THING  as  values. 

3.  The  order-spec-relationship  slot  is  one  of  the  symbols  <,  <=,  or  =. 

The  interpretation  is  that  the  instance  denoted  by  order-spec-a  has  the  relationship  specified 
by  order-spec-relationship  to  order-spec-b. 

6.2.  Uses  of  the  Ontology 

The  GH  ontology  uses  Partial-Order  to  specify  relationships  among  values  in  coded  domains. 
These  domains  are  string-valued  codes.  Most  of  the  codes  are  written  such  as  to  be  in  a  lexi¬ 
cographic  order  that  also  corresponds  to  a  logical  ordering  between  elements,  where  such  an 
ordering  is  possible.  However,  the  ordering  is  not  uniform.  Some  domains  have  smallest 
elements  first,  some  have  largest  elements  first.  Moreover,  some  domains  are  partial  and  not 
total  orders  (for  instance,  unit  size  code),  and  almost  all  include  the  element  NOS  (not  other¬ 
wise  specified)  which  should  not  be  considered  in  any  order. 

The  Partial-Order  ontology  lets  the  order  among  elements  be  explicitly  specified.  One  element 
can  be  stated  as  being  less  than,  less  than  or  equal  to,  or  equal  to  another  element.  Transitive 
properties  can  be  applied  to  detennine  if  a  relationship  exists  between  a  given  pair  of  ele¬ 
ments.  The  model  of  unit  size,  which  in  the  GH  data  model  encompasses  units  from  air,  land, 
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and  sea  branches  of  the  services,  is  the  most  complete  application  of  an  ordering  specifica¬ 
tion  in  the  GH  ontology. 

For  the  ordering  to  make  sense,  the  values  of  order-spec-a  and  order-spec-b  must  be  from  the 
same  domain.  This  is  enforced  using  the  following  PAL  constraint: 

(defrange  ?os  :FRAME  Order-Specification) 

(forall  ?os 

(and  (instance-of  (order-spec-b  ?os)  (get-class  (order-spec-a  ?os))) 

(instance-of  (order-spec-a  ?os)  (get-class  (order-spec-b  ?os))))) 

Protege-2000  requires  an  application  or  user  to  apply  this  constraint  explicitly;  it  is  not  auto¬ 
matically  enforced. 

Currently  an  application  must  examine  the  ontology  to  determine  ordering  constraints.  A 
plugin  would  be  preferable,  but  has  not  been  implemented  because  of  time  constraints. 

7.  The  Units  of  Measurement  Ontology 

The  Units  ontology  models  different  units  of  measurement.  It  builds  on  the  Measurable-Things 
ontology  by  describing  different  standards  by  which  a  property  can  be  measured.  Like 
Measurable-Things,  it  includes  a  capability  to  specify  interrelationships  between  instances. 
Figure  5  shows  the  classes  in  the  ontology.  Unit-of-Measurement  and  Unit-of-Measurement- 
Mapping  are  both  subclasses  of  THING. 

<?  1  c)  U in  it-  of-  M  e  a  s  u  re  m  e  nt 
(c)  Composite-Unit 

9  'T-i  U_nit-of-Measurement-MappingA 
9  (p)  Unit-Mapping-One-To-One  A 
c:  Unit-Mapping-Multiplicative 
(c)  Unit-Mapping-Additive 
(c)  Unit-Mapping-Complex 
(c)  Unit-Mapping-Many-To-One 

Figure  5.  Classes  of  the  Units  Ontology 

7.1.  Slots  of  Unit-of-Measurement 

Each  instance  of  the  Unit-of-Measurement  class  denotes  a  unit  of  measurement.  The  class  has 
the  following  slots: 

•  The  unit-name  slot  is  used  to  supply  a  textual  name  for  an  instance.  The  value  should 
be  a  full  name,  not  an  abbreviation.  The  value  could  be  used  as  metadata.  The  slot’s 
value  must  be  unique  with  respect  to  a  knowledge  base. 

•  The  unit-symbol  slot  is  a  multiple-cardinality  slot  whose  values  are  strings.  It  is  used  to 
list  common  abbreviations  and  symbols  for  a  unit  of  measurement.  (Protege-2000  is 
not  restricted  to  ASCII;  it  supports  the  UTF-8  coding  system,  so  ontology  developers 
can  use  non-textual  glyphs  as  symbols.)  If  the  unit-name  slot  has  the  value  kilometer, 
the  unit-symbol-slot  might  have  values  km  and  k.  These  values  can  also  be  used  as 
metadata,  but  they  are  not  required,  nor  even  expected,  to  be  unique  across  a  knowl¬ 
edge  base. 

•  The  unit-base-type  slot  specifies  the  most  natural  numeric  representation  for  the  in¬ 
stance.  Its  possible  values  are  integer,  real,  complex,  and  string.  The  GH  ontology  only 
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uses  integer  and  real.  The  slot  gives  an  indication  as  to  the  nature  of  a  unit:  whether  or 
not  it  records  a  quantity  (usually  an  integer),  for  example. 

•  The  unit-concept  slot  describes  the  concept  that  the  unit  of  measurement  models.  It  is  a 
multiple  cardinality  slot  whose  values  are  instances  of  either  Measurable-Thing  or 
Enumerable-Thing. 

•  The  unit-range-min  and  unit-range-max  slots  specify  minimum  and  maximum  permitted 
values  for  the  unit.  These  slots  are  optional.  However,  many  units  of  measurement 
cannot  be  less  than  zero  (especially  quantities)  or  some  arbitrary  value  (  e.g.,  degrees 
Celsius).  A  maximum  value  is  less  common  but  still  useful  for  angles,  color  hues,  and 
the  like.  It  may  also  be  useful  in  some  domains  to  prevent  nonsensical  values. 

Here  is  an  instance  of  class  Unit-of-Measurement: 


unit-name 

unit-symbols 

unit-base-type 

unit-concept 

unit-range-min 

unit-range-max 


kilometer 
{  k,  km  } 
real 

Distance  (instance  of  Measurable-Thing) 
0.0 

38000 


The  value  for  unit-range-max  is  the  approximate  circumference  of  the  Earth  in  kilometers. 
This  would  be  a  reasonable  maximum  value  for  land-based  warfare. 

Class  Unit-of-Measurement  has  a  subclass  Composite-Unit-of-Measurement.  This  subclass  is  used 
to  model  units  of  measurement  that  are  composed  of  other  units  of  measurement,  as 
Composite-Measurable-Thing  models  non-atomic  measurable  things.  Composite-Unit-of- 
Measurement  has  a  template  slot  unit-constituent-units.  This  slot  is  of  multiple  cardinality;  its 
values  are  instances  of  Unit-of-Measurement  that  make  up  this  instance.  The  following  is  an 
example: 


unit-name 

unit-symbols 

unit-base-type 

unit-concept 

unit-range-min 

unit-range-max 


kilometers  per  hour 
{  km/hr,  kph  } 
real 

Speed  (instance  of  Measurable-Thing) 
0.0 

[not  specified] 


unit-constituent-units  {  kilometer,  hour  } 


The  values  for  unit-constituent-units  must  include  one  value  for  each  constituent.  Thus  its  value 
for  square  meters  is  {  meter,  meter  } .  The  order  of  the  values  is  not  significant.  Note  that  the 
Composite-Unit-Measurement  class  does  not  contain  enough  information  to  infer  how  constitu¬ 
ent  units  form  a  composite  unit.  Future  versions  of  the  Units  ontology  may  need  to  add  this 
information,  depending  on  inference  needs. 

The  values  for  the  unit-range-min  and  unit-range-max  slots  are  instances  of  all  subclasses  of 
Numeric-Expression  except  Variable.  The  intent  is  that  the  minimum  and  maximum  values 
should  be  constants,  either  literals  or  expressions  that  evaluate  to  constants.  Of  course,  an 
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instance  of  an  expression  can  contain  a  Variable  instance  as  an  operand.  This  violation  is  not 
detected. 

7.2.  Slots  of  Unit-of-Measurement-Mapping 

The  Unit-of-Measurement-Mapping  class  specifies  how  one  unit  can  be  converted  to  another 
unit.  The  conversion  is  specified  as  a  restricted  Numeric-Expression;  the  restriction  depends  on 
the  type  of  mapping.  The  class  has  two  template  slots: 

1.  The  unit-mapping-label  slot  specifies  a  textual  label.  It  is  used  as  the  form  browser  key. 

2.  The  to-unit  slot  specifies  the  Unit-of-Measurement  instance  that  is  the  target  of  this  map¬ 
ping.  That  is,  to  specify  a  mapping  from  some  unit  to  kilometers,  one  specifies  that 
the  kilometer  instance  of  Unit-of-Measurement  is  the  target  of  this  mapping. 

Class  Unit-of-Measurement-Mapping  is  abstract.  The  nature  of  a  mapping  is  specified  in  a  sub¬ 
class.  Unit-of-Measurement-Mapping  has  two  subclasses.  One  handles  one-to-one  mappings,  the 
other  many-to-one  mappings. 

7.2.1.  Slots  of  Unit-Mapping-One-to-One 

The  Unit-Mapping-One-to-One  class  specifies  a  mapping  from  one  unit  of  measurement  to  an¬ 
other.  The  target  unit  is  specified  by  the  to-unit  slot  of  the  parent  class.  This  class  has  a  tem¬ 
plate  slot  from-unit  that  specifies  the  source  unit  of  measurement;  its  value  is  an  instance  of 
Unit-of-Measurement. 

Usually  the  unit-concept  slot  of  the  from-unit  and  to-unit  instances  will  refer  to  the  same 
Measurable-Thing  (or  Enumerable-Thing)  instance.  This  is  not  required,  because  the  unit-concept 
slot  has  multiple  cardinality  to  account  for  units  of  measurement  that  express  multiple  con¬ 
cepts.  An  example  is  degrees  in  the  sense  of  location;  degrees  can  refer  to  both  latitude  and 
longitude.  Arguably,  this  flexibility  leads  to  imprecision,  and  requiring  equivalence  of  con¬ 
cepts  between  the  from-unit  and  to-unit  slots  would  be  better.  (In  that  case  a  knowledge  base 
would  have  to  express  degrees  of  latitude  and  degrees  of  longitude  as  distinct  units  of  meas¬ 
urement.) 

The  Unit-Mapping-One-to-One  class  is  abstract,  but  has  three  subclasses,  each  of  which  ex¬ 
presses  a  specific  kind  of  one-to-one  mapping  between  units  of  measurement: 

1.  The  Unit-Mapping-Multiplicative  class  denotes  a  mapping  between  units  expressed  as  a 
constant  multiplier.  It  has  a  template  slot  multiplier,  whose  value  is  an  instance  of  class 
Literal,  to  denote  the  multiplier.  The  relationship  between  centimeters  and  millimeters 
can  be  expressed  using  this  class: 

unit-mapping-label  cm  =>  mm 

from-unit  Centimeter  (instance  of  Unit-of-Measurement) 

to-unit  Millimeter  (instance  of  Unit-of-Measurement) 

multiplier  1  o  (instance  of  Integer-Literal) 

2.  The  Unit-Mapping-Additive  class  denotes  a  mapping  between  units  expressed  as  a  differ¬ 
ence  in  magnitude.  It  has  a  template  slot  additive-factor,  whose  value  is  an  instance  of 
class  Literal,  to  denote  the  difference.  The  relationship  between  degrees  Kelvin  and 
degrees  Celsius  is  expressed  as  follows  as  an  instance  of  Unit-Mapping-Additive: 
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unit-mapping-label  °K  =>  °C 

from-unit  degrees  Kelvin  (instance  of  Unit-of-Measurement) 

to-unit  degrees  Celcius  (instance  of  Unit-of-Measurement) 

multiplier  273  (instance  of  Integer-Literal) 

3.  The  Unit-Mapping-Complex  class  denotes  a  mapping  between  units  that  must  be  ex¬ 
pressed  as  a  function  of  the  source  unit.  It  has  a  template  slot  relating-expression.  The 
value  of  this  slot  is  an  instance  of  a  Numeric-Expression.  The  expression  must  involve 
an  instance  of  class  Instance-Variable  that  refers  to  a  Unit-of-Measurement  instance. 
Analogous  to  the  Measurable-Things  ontology,  the  Units  ontology  extends  class 
Instance-Variable  with  a  subclass  Unit-lnstance-Variable,  and  the  instance  variable  con¬ 
tained  in  the  Numeric-Expression  should  be  instances  of  this  class.  As  with  the 
Measurable-Things  ontology,  this  constraint  is  not  enforced. 

The  Unit-Mapping-Complex  class  is  used  to  specify  a  mapping  from  degrees  Celsius  to 
degrees  Fahrenheit.  The  formula  used  is: 

(Sum 

(Product 

(Division 

(Integer-Literal  9) 

(Integer-Literal  5)) 

(Unit-Instance-Variable  :variable-ref  [degrees  Celsius])) 

(Integer-Literal  32)) 

7.2.2.  Slots  of  Unit-Mapping-Many-to-One 

The  Unit-Mapping-Many-to-One  class  models  mappings  from  a  set  of  units  to  a  composite  unit 
of  measurement.  The  class  has  the  following  template  slots: 

1.  The  to-unit  slot  is  overridden  such  that  its  value  must  be  an  instance  of  Composite-Unit 
rather  than  Unit-of-Measurement. 

2.  The  from-units  slot  models  the  units  of  measurement  that  form  the  source  of  this  map¬ 
ping  instance.  It  is  a  multi-cardinality  slot  whose  values  must  be  instances  of  Unit-of- 
Measurement.  At  least  one  value  is  required. 

3.  The  many-to-many-mapping-expr  slot  is  an  instance  of  Numeric-Expression  specifying  a 
formula  that  describes  the  mapping.  The  formula  should  contain  an  instance  of  the 
Unit-lnstance-Variable  class  for  each  value  in  the  from-units  slot,  and  the  Unit-lnstance- 
Variable  instances  should  refer  to  these  values  in  the  variable-ref  slots.  The  ontology 
does  not  enforce  this  requirement. 

For  example,  the  Units  ontology  specifies  a  mapping  from  kilometers  and  hours  to  kilometers 
per  hour  as  follows: 

unit-mapping-label  km/hr  =>  kph 

from-units  {  kilometer,  hour  } 

to-unit  kilometers  per  hour  (Instance  of  Composite-Unit) 

many-to-one-mapping-expr  (Division 

(Unit-lnstance-Variable  :variable-ref  [kilometer]) 
(Unit-lnstance-Variable  :variable-ref  [hour])) 
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7.3.  Instances  of  the  Ontology 

The  Units  ontology  contains  instances  for  those  units  of  measurement  commonly  used  in  the 
GH  data  model  to  reflect  physical  properties.  The  GH  data  model  uses  the  metric  system,  so 
the  Units  ontology  contains  meter,  liter,  kilometer,  etc.  The  Units  ontology  contains  English 
units  as  well. 

The  Units  ontology  contains  mappings  between  common  units.  Examples  include  converting 
between  metric  length  units  (centimeter  to  millimeter,  meter  to  centimeter)  and  conversions 
between  English  and  metric  units  (inch  to  centimeter,  square  meter  to  square  foot). 

The  GH  data  model  attribute  capability-unit-of-measure-code  specifies  a  large  set  of  units.  The 
Units  ontology  should  ultimately  contain  all  those  units. 

7.4.  Uses  of  the  Ontology 

The  Types  ontology  makes  extensive  use  of  the  Unit-of-Measurement  class  to  allow  a  type  to  be 
attached  to  a  unit.  In  the  GH  ontology,  each  slot  that  models  a  physical  property  is  of  a  type 
that  has  an  attached  Unit-of-Measurement  instance.  The  means  by  which  this  is  accomplished 
are  discussed  in  the  next  section. 

The  Unit-of-Measurement-Mapping  class  is  not  currently  used.  It  was  developed  to  support  rea¬ 
soning  capabilities  that  so  far  have  not  been  needed  in  the  sample  applications  that  use  the 
ontology. 

The  Units  ontology  contains  a  PAL  constraint  that  enforces  uniqueness  of  type  names.  It  is  up 
to  applications,  or  to  users,  to  ensure  that  this  constraint  is  satisfied;  Protege-2000  will  no 
enforce  it  automatically. 

The  Units  ontology  is  a  building  block,  and  therefore  it  is  the  responsibility  of  any  ontology 
that  uses  it  to  establish  a  proper  framework  for  interpreting  units  of  measurement.  One  aspect 
of  this  framework  is  adherence  to  the  criteria  established  by  the  unit-range-min  and  unit-range- 
max  slots  so  that  they  are  satisfied  for  any  instance  declared  to  be  of  a  particular  unit.  This 
particular  case  is  discussed  for  the  Types  ontology  in  Section  8.  Protege-2000  will  not  enforce 
adherence  automatically,  but  an  ontology  can  specify  a  contract  between  itself  and  an  appli¬ 
cation  or  user,  adherence  to  which  will  guarantee  constraint  satisfaction. 

8.  The  Types  Ontology 

The  Types  ontology  models  data  types  -  domains  of  values.  These  values  may  share  ele¬ 
ments,  but  they  are  distinguishable.  The  Types  ontology  is  a  building  block  that  allows  an¬ 
other  ontology  to  distinguish  domains  of  slots  beyond  the  few  primitive  types  offered  by  Pro¬ 
tege-2000  and  other  knowledge  base  development  tools.  This  distinction  is  important  in  the 
GH  data  model,  where  (for  example)  string-valued  attributes  have  a  specified  maximum 
length.  Protege-2000  does  not  allow  maximum  string  length  to  be  specified. 

Many  GH  data  model  attributes  are  represented  as  a  six-character  string  denoting  a  code. 
Protege-2000  allows  the  values  for  a  slot  to  come  from  a  prespecified  set  of  strings,  which 
could  constrain  possible  values  to  the  desired  set.  However,  it  doesn’t  describe  the  different 
meaning  a  code  can  have.  The  value  'AT'  can  mean,  in  different  contexts,  the  Ashmore  and 
Cartier  Islands,  an  anti-tank  weapon,  and  specified  time. 

In  an  ontology,  it  is  important  to  have  as  much  infonnation  as  possible  about  the  possible 
value  for  a  slot.  The  Types  ontology  works  towards  that  end. 
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The  Types  ontology  also  assigns  meaning  to  a  slot.  At  the  most  primitive  level,  meaning  is 
assigned  in  terms  of  a  type’s  name  and  its  relationship  to  other  types  in  the  type  hierarchy 
(see  Figure  6).  More  complex  meaning  comes  from  use  of  the  ontologies  discussed  in  the 
previous  sections.  How  this  is  achieved  will  be  discussed  shortly. 

9  9  TypeA 

9  1 ©  Enumerated-Type* 

©  Month-Type 
c  Colors 

9  9' Numeric-Type  A 
9  9'  Integral-Type  A 

9  1 9 1 1  nte  g  ra  l-Ty  p  e-  C  o  m  p  ute  r-  R  e  I  ate  d  A 
9'  1 6-bit  signed  integer 
1 91  32-bit  signed  integer 
9  1 9'  Integral-Type-Decimal-Domain  A 
1 ©  Year-Class 

9  '■  9 '  Integral-Type-Domain-Independent* 

©  integer 
©  natural 
9  c  Real-Type* 

9  9'  Real-Type-Decimal A 
1 91  Duration 

9  1 9'  Real-Type-Unbounded  A 
©  Radiation-Dose 
(.9)  Real-Type-Scientific-Notation  A 
9  ©String-Type* 

9  1 9'  String-Type- Varying  A 

9 1  Unformatted  Descriptive  String 
91  String-Type- Fixed* 

©  Boolean-Type* 

9  1 9’ Date-Type* 

©  A.D.  Date 
9  ©Time-Type* 

©)  Seconds  Up  to  24  Hours 
1 c  DateTime-Type 

Figure  6.  Classes  in  the  Types  Ontology:  Type  Hierarchy 
The  Types  ontology  includes  a  basic  hierarchy  of  types  categorized  according  to  representa¬ 
tion.  The  intent  is  to  assist  users  in  placing  and  locating  types.  Thus  Figure  6  shows,  as  sub¬ 
classes  of  Type,  classes  for  representing  enumerations,  numeric  types,  string  types,  Boolean 
types,  date  times,  time  types,  and  date/time  types.  These  classes  are  further  subdivided  into 
according  to  representation:  integers  vs.  real  numbers,  fixed  vs.  varying  length  strings,  etc. 
Only  leaves  of  the  hierarchy  are  concrete;  the  interior  classes  are  all  abstract. 

An  ontology  defines  a  type  not  by  creating  an  instance  but  by  creating  a  subclass  somewhere 
in  the  Type  hierarchy.  Figure  6  contains  some  illustrative  classes,  such  as  16-bit  signed  integer, 
Duration,  and  Seconds  Up  to  24  Hours.  The  meaning  of  these  classes  should  be  clear  enough  to 
a  reader  based  on  their  name,  but  their  meaning  to  an  application  is  less  clear.  Section  8.2 
will  discuss  how  additional  properties  are  associated  with  each  of  these  classes. 

8.1.  Slots  of  the  Type  Class 

The  Type  class  contains  a  single  template  slot  named  type-instance-value.  Its  meaning  and  use 
require  some  explanation.  An  ontology  uses  the  Types  ontology  to  model  the  types  of  organic 
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slots.  Each  organic  slot’s  value  should  be  declared  to  be  an  instance  of  some  subclass  of 
Type.  Organic  slots  therefore  do  not  use  Protege-2000’s  built-in  domains  directly.  Instead, 
they  refer  indirectly  to  these  domains.  The  value  of  slot  type-instance-value  for  an  instance  is 
an  appropriate  domain,  such  as  a  Protege-2000  string. 

Figure  7  shows  an  example.  The  GH  ontology  has  a  class  Object-Item  with  two  template  slots: 
name  and  alternate-identification-text.  A  value  for  the  name  slot  must  be  an  instance  of  Object- 
Item-Name,  which  the  GH  ontology  declares  as  a  subclass  of  String-Type-Varying.  In  class 
String-Type-Varying  the  value  type  of  slot  type-instance-value  is  overridden  to  be  a  string.  Creat¬ 
ing  a  value  for  the  name  slot  entails  creating  an  instance  o  of  Object-Item-Name,  assigning  the 
string  denoting  the  object  item’s  name  to  the  type-instance-value  slot  of  o,  then  assigning  o  to 
be  the  value  of  the  name  slot. 


GH  Entity  Type  Subclass  Property  Value 


Figure  7.  Representing  Organic  Slot  Values 
Creating  a  value  for  the  alternate-identification-text  slot  is  similar,  except: 

•  The  string  denoting  the  alternate  identifier  is  assigned  to  the  type-instance-value  slot  of 
an  instance  of  class  Unformatted-Descriptive-String  rather  than  Object-Item-Name. 

•  The  GH  ontology  specifies  that  the  value  type  of  the  alternate-identification-text  slot 
must  be  an  instance  of  Unformatted-Descriptive-String  rather  than  Object-Item-Name. 

Thus  it  is  not  possible  to  assign  an  alternate  identifier  to  a  name.  In  this  way  the  Types  ontol¬ 
ogy  establishes  the  means  by  which  another  ontology  can  specify  strict  typing.  (However, 
Protege-2000  doesn’t  enforce  strict  typing;  the  knowledge  base  user  has  that  responsibility. 
The  Types  ontology  simply  provides  enough  infonnation  to  make  strict  typing  possible.) 

Sometimes  the  domain  of  type-instance-value  is  another  class  defined  as  part  of  the  GH  ontol¬ 
ogy  hierarchy,  such  as  Numeric-Expression.  In  that  case  the  value  of  the  type-instance-value  slot 
will  be  an  instance  of  Numeric-Expression.  The  intent  of  allowing  numeric  expressions  is  to 
facilitate  recording  exact  values,  and  to  show  their  derivation:  If  one  slot  has  the  value  a  +  b 
and  another  has  the  value  l/(a  +  b) ,  the  fact  that  a  knowledge  base  uses  the  same  instance  of 
Numeric-Expression  to  represent  a  +  b  may  explain  some  similarity.  Of  course,  a  Literal  is  a 
Numeric-Expression,  and  in  practice  most  slot  values  will  be  instances  of  Literal. 

Subclasses  of  Type  have  no  slots  other  than  type-instance-value.  Additional  properties  are  de¬ 
scribed  using  a  metaclass. 

8.2.  Metaclasses  in  the  Types  Ontology 

A  subclass  of  Type  contains  no  infonnation  about  a  type  other  than  what  can  be  gleaned  from 
its  name  and  relative  location  in  the  class  hierarchy.  This  information  is  useful  to  humans  but 
provides  no  real  infonnation  that  applications  or  other  ontologies  might  use  for  reasoning. 
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To  let  this  information  be  added,  the  Types  ontology  declares  metaclasses.  In  Protege-2000, 
every  class  has  a  metaclass.  The  slots  associated  with  a  metaclass  are  exactly  those  slots  an 
ontology  developer  uses  to  characterize  a  class.  The  default  metaclass  is  class  :STANDARD- 
CLASS,  a  subclass  of  :CLASS,  and  its  slots  are  the  default  properties  for  a  class:  name,  template 
slots,  concrete  or  abstract,  etc.  Any  subclass  of  class  :CLASS  is  a  valid  meta-class.  The  usual 
approach  to  adding  metaclasses  to  an  ontology  is  to  extend  :STANDARD-CLASS,  as  Protege-2000 
is  programmed  to  understand  the  slots  associated  with  :STANDARD-CLASS.  To  declare  meta¬ 
classes  that  are  descendants  of  :CLASS  but  not  of  :STANDARD-CLASS  would  necessitate  the  time- 
consuming  task  of  writing  a  plugin. 

Figure  8  shows  the  metaclasses  declared  by  the  Types  ontology  in  support  of  expressing  type- 
related  information.  The  metaclasses  are  rooted  by  Type-Class,  a  subtype  of  :STANDARD-CLASS. 
Descended  from  Type-Class  are  classes  that  characterize  different  kinds  of  data  types.  The  set 
of  classes  is  based  on  needs  of  the  GH  ontology.  Other  ontologies  may  need  to  add  other 
classes. 

The  descendents  of  Type-Class  are  hierarchically  organized  based  on  characteristics  of  a  do¬ 
main.  Four  characteristics  are  recognized: 

1.  Textual  domains,  in  which  the  elements  are  strings.  Values  of  these  domains  tend  to 
be  descriptive  rather  than  analytic. 

2.  Enumerable  domains,  in  which  there  exist  a  finite  set  of  elements.  This  does  not  ex¬ 
clude  domains  that  may  be  enumerated  using  ordinal  numbers. 

3.  Measurable  domains,  in  which  a  value  directly  describes  a  physical  or  conceptual 
property. 

4.  Numerically  describable  domains,  in  which  a  value  describes  a  numerical  amount  of 
some  entity. 


©  THING  A 

9  ©:SYSTEM-CUSSA 
9  ©  :CLASS  A 

9  ©  :STANDARD-CLASS 
9  ©  Type-Class 
9  ©Textual-Class 

©  Formatted-Textual-Class 
( ©  Unformatted-Textual-Class 
9  9' Enumerable-Class  A 

9  ©  Labeled-Enumerable-Class 

©  Labeled-Enumerable-Class-Mapping-to-Type 
©)  Labeled-Enumerable-Class-Mapping-To-Measurement 
9  c  Integrally-Enumerable-Class 

c  Integrally-Enumerable-Class-Describing-Class 
©  Boolean-Class 
c  Tri-State-Class 
©  Fractional-Class 
9  1  ©  Measurable-ClassA 

9  ©  Numerically-Measurable-Class 

9  ©  Numerically-Measurable-Real-Class 

©  Numerically-Measurable-Decimal-Real-Class 
1  ©  Numerically-Describable-Class 
Figure  8.  Metaclasses  for  Specifying  Type  Information 
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These  characteristics  are  not  mutually  exclusive.  Some  enumerable  domains  are  also  measur¬ 
able,  and  vice  versa.  The  slots  of  a  metaclass  help  an  ontology  developer  decide  whether  it  is 
most  appropriate. 

The  metaclass  Type-Class  has  no  template  slots.  It  exists  to  distinguish  type-related  meta¬ 
classes  from  other  metaclasses  an  ontology  may  declare.  Moreover,  it  is  not  an  abstract  class. 
It  is  a  useful  placeholder  for  domains  that  an  ontology  does  not  otherwise  characterize. 

8.2.1.  Metaclasses  for  Textual  Domains 

An  ontology  developer  declares  a  type  (i.e.,  a  subclass  of  Type)  to  have  a  metaclass  that  is  a 
subclass  of  Textual-Class  when  the  type  is  meant  to  model  strings.  Textual-Class  has  two  tem¬ 
plate  slots: 

1.  The  textual-class-varying  slot  is  a  Boolean-valued  slot  that  specifies  if  the  domain  is  to 
consist  of  varying-length  or  fixed-length  strings. 

2.  The  textual-class-string-length  slot  declares  the  maximum  permitted  length  for  any 
string  in  the  domain.  If  the  textual-class-varying  slot  is  false,  then  the  maximum  length 
is  also  the  minimum  length. 

Class  Textual-Class  has  two  subclasses:  Formatted-Textual-Class  and  Unformatted-Textual-Class. 
The  former  is  used  to  model  domains  in  which  the  values  have  a  specified  format.  This  for¬ 
mat  is  described  by  the  template  slot  formatted-textual-class-format-description.  The  Types  ontol¬ 
ogy  does  not  assign  any  meaning  to  the  content  of  this  slot;  applications,  users,  and  other  on¬ 
tologies  are  free  to  interpret  it.  Possibilities  include  regular  expressions  and  hyperlinks  to  ex¬ 
ternal  standard  definitions  (the  latter  is  more  logical  in  a  net-centric  environment,  if  more  ex¬ 
pensive  to  implement). 

Class  Unformatted-Textual-Class  is  used  for  string-valued  domains  that  have  no  format  con¬ 
straints. 

The  metaclass  does  not  specify  a  character  set.  This  extension  would  be  useful  in  net-centric 
environments  and  should  be  added  to  a  future  version  of  the  Types  ontology. 

8.2.2.  Metaclasses  for  Enumerable  Domains 

An  ontology  developer  declares  a  type  to  have  a  metaclass  that  is  a  subclass  of  Enumerable- 
Class  when  the  type  models  a  fixed  set  of  values.  These  values  need  not  have  a  string  repre¬ 
sentation.  Any  enumerable  set  -  integers,  logical  values,  or  even  real  numbers  -  will  do  in 
theory.  The  Types  ontology  does  not  currently  support  enumerations  of  real  numbers. 

The  Enumerable-Class  metaclass  has  no  template  slots.  It  is  the  root  of  a  hierarchy  of  enumer¬ 
able  class  kinds. 

8.2.2. 1 .  Labeled  Enumerable  Classes 

The  first  kind  of  enumeration  supported  by  the  Types  ontology  is  a  labeled  enumerable  class. 
In  this  class,  each  element  of  the  enumeration  has  a  label  that  is  not  presumed  to  have  any 
meaning  when  compared  to  other  elements.  This  is  in  contrast  to  integrally  enumerable 
classes,  where  the  elements  have  an  inherent  order. 

Labeled-Enumerable-Class  has  two  template  slots.  The  first,  which  is  required  to  have  at  least 
one  value,  is  named  labeled-enumerable-class-elements.  Its  values  are  instances  of  a  subclass  of 
Enumerated-Element,  which  is  a  subclass  of  THING.  Section  8.4  covers  the  Enumerated-Element 
class  in  detail.  For  now,  it  is  sufficient  to  know  that  the  class  has  two  template  slots.  The  first 
denotes  the  six-character  label  of  the  element.  The  second  models  the  descriptive  text  that 
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accompanies  each  GH  code.  All  values  of  labeled-enumerable-class-elements  must  be  instances 
of  the  same  class. 

The  second  template  slot  of  Labeled-Enumerable-Class  is  named  labeled-enumerable-class- 
element-ordering.  This  slot  allows  information  on  ordering  among  elements  to  be  given, 
should  such  infonnation  make  sense  for  an  enumeration.  An  ordering  is  stated  as  a  set  of 
Order-Specification  instances  (see  Section  6).  The  own  slots  of  an  Order-Specification  instance 
specify  two  elements;  these  elements  must  be  instances  of  the  elements  given  by  the  labeled- 
enumerable-class-elements  slot. 

The  GH  ontology  has  many  labeled  enumerable  classes  (that  is,  subclasses  of  Enumerated- 
Type  whose  metaclass  is  Labeled-Enumerable-Class).  These  enumerations  tend  to  be  those 
about  which  little  can  be  inferred,  except  perhaps  ordering  infonnation.  More  interesting  are 
the  two  subclasses  of  Labeled-Enumerable-Class: 

1.  Class  Labeled-Enumerable-Class-Mapping-To-Type  serves  as  a  metaclass  for  those  enu¬ 
merations  in  which  the  instances  describe  some  subclass  of  Type.  It  has  a  template 
slot  labeled-mapping-to-type  that  records  this  class.  For  example,  the  GH  attribute 
capability-day-night-code  has  values  that  describe  a  period  of  a  24  hour  day:  DAY  (day¬ 
time),  N  (nighttime),  and  DN  (daytime  or  nighttime).  Because  daytime  varies  with 
each  day  of  the  year,  these  values  do  not  correspond  to  any  precise  time  range  until 
placed  in  context.  However,  one  can  still  note  that  the  code  corresponds  to  some  time 
range.  Thus  the  corresponding  class  in  the  GH  ontology, 
DS181_capab_day_night_code,  uses  Labeled-Enumerable-Class-Mapping-to-Type  as  its 
metaclass,  and  has  class  DateTime-Type  (see  Section  8.3.7)  as  the  value  of  its  labeled- 
mapping-to-type  own  slot. 

2.  Class  Labeled-Enumerable-Class-Mapping-To-Measurement  is  the  metaclass  for  enumera¬ 
tions  in  which  instances  are  codes  denoting  some  measurement.  The  class  has  two 
template  slots:  labeled-enumerable-class-mtm-measurable-thing  and  labeled-enumerable- 
class-mtm-units-of-measurement.  These  describe,  respectively,  the  thing  that  each  in¬ 
stance  measures,  and  the  units  in  which  it  is  measured.  (The  details  of  the  measure¬ 
ment  are  a  property  of  an  enumerated  element  instance,  and  are  specified  in  the  in¬ 
stance  of  Enumerated-Element.)  For  example,  the  GH  attribute  organisation-status- 
radiation-dose-code  has  values  1,  2,  and  3,  each  of  which  gives  a  range  of  radiation  ex¬ 
posure  measured  in  centigrays.  Thus  the  DS394_rad_dose_code  class  in  the  GH  ontol¬ 
ogy  uses  Labeled-Enumerable-Class-Mapping-To-Measurement  as  its  metaclass,  with 
Radiation  Dose  as  the  measurable  thing,  and  centigray  as  the  unit  of  measurement. 

As  another  example,  the  GH  data  model  attribute  action-task-start-precision-code  has 
values  DAY  (day),  HR  (hour),  and  MINUTE  (minute)  that  denote  the  precision  of  meas¬ 
urement  for  determining  when  a  task  will  commence.  These  values  correspond  to  the 
measurable  thing  “time”,  of  which  an  instance  is  defined  in  the  Measurable-Things  on¬ 
tology.  Thus  the  DS284_timing_precision_code  class  in  the  GH  ontology  uses  Labeled- 
Enumerable-Class-Mapping-To-Measurement  as  its  metaclass,  with  Time  as  the  measur¬ 
able  thing.  The  slot  describing  units  of  measurement  is  left  undefined,  because  for 
this  enumeration  each  value  is  a  distinct  unit  of  measurement. 
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8.2. 2.2.  Integrally  Enumerable  Classes 

An  integrally  enumerable  class  is  one  in  which  the  enumerated  values  are  integers  rather  than 
character  strings.  A  class  that  uses  Integrally-Enumerable-Class  as  its  metaclass  has  values  that 
are  naturally  countable,  as  opposed  to  using  integers  as  arbitrary  labels.  For  this  reason, 
DS394_rad_dose_code  is  not  an  integrally  enumerable  class,  but  values  such  as  quantity  of 
beds,  candidate  target  priority,  and  line  point  sequence  are.  Note  too  that  these  values  are  not 
what  one  would  normally  think  of  as  measurements,  though  this  is  arguable. 

Integrally-Enumerable-Class  has  two  template  slots:  minimum  and  maximum.  These  slots  pre¬ 
scribe  minimum  and  maximum  values  for  the  domain  that  an  instance  of  Integrally- 
Enumerable-Class  models. 

The  Types  ontology  declares  five  primitive  types  as  integrally  enumerable: 

1.  Class  integer,  which  denotes  an  integer.  The  class  has  no  predefined  minimum  or  maxi¬ 
mum. 

2.  Class  natural,  which  denotes  the  natural  integers.  The  class  has  a  minimum  of  0,  and 
no  predefined  maximum. 

3.  Class  16-bit  signed  integer,  which  has  a  minimum  of  -32,768  and  a  maximum  of 
32,767. 

4.  Class  32-bit  signed  integer,  which  has  a  minimum  of  -2,147,483,648  and  a  maximum  of 
2,147,483,647. 

5.  Class  A.D.  Date,  which  is  intended  to  model  dates  between  1  January  1  and  31  De¬ 
cember  9999.  The  class  has  no  predefined  minimum  or  maximum,  however.  (In  other 
words,  its  definition  is  incomplete.) 

Despite  sharing  the  same  metaclass,  these  classes  are  distributed  throughout  the  class  hier¬ 
archy  rooted  at  Type  (see  Figure  6). 

Integrally-Enumerable-Class  has  a  subclass  named  Integrally-Enumerable-Class-Describing-Class.  It 
serves  as  the  metaclass  of  classes  that  enumerate  some  class  in  the  ontology.  It  has  a  single 
template  slot  named  integrally-enumerable-class-referenced-class  whose  value  type  is  a  class. 
For  example,  the  GH  data  model  attribute  holding-quantity  is  modeled  in  the  GH  ontology  as  a 
slot  whose  domain  is  the  class  Holding-Quantity.  Holding-Quantity,  a  subtype  of  Type,  uses 
Integrally-Enumerable-Class-Describing-Class  as  its  metaclass.  The  own  slot  value  of  integrally- 
enumerable-class-referenced-class  for  the  Holding-Quantity  class  is  the  Object-Type  class.  For  an 
associative  class  such  as  Holding,  the  Integrally-Enumerable-Class-Describing-Class  metaclass 
identifies  the  class  to  which  a  slot  refers. 

8. 2.2. 3.  Boolean  Classes 

A  Boolean  class  is  one  with  two  values,  one  of  which  can  be  mapped  to  truth  and  the  other  to 
falsehood.  Boolean-Class  serves  as  the  metaclass  for  these  classes.  It  has  two  template  slots: 
bool-type-true-literal  and  bool-type-false-literal,  which  denote  the  literal  values  for  truth  and  false¬ 
hood,  respectively,  for  a  domain.  The  metaclass  is  motivated  by  the  many  GH  coded  domains 
that  use  YES  and  NO  instead  of  true  and  false. 

8.2. 2.4.  Tri-State  Classes 

Tri-State  logic  has  three  values:  truth,  falsehood,  and  indetenninacy.  Tri-State-Class  serves  as 
the  metaclass  for  type  classes  that  model  tri-state  logic  domains.  It  has  three  template  slots: 
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bool-type-true-literal,  bool-type-false-literal,  and  tri-state-type-unknown-literal.  The  metaclass  is  mo¬ 
tivated  by  the  GH  data  model  coded  domains  that  add  an  “unknown”  code  to  a  domain  ex¬ 
pressing  truth  and  falsehood. 

8.2.3.  Metaclasses  for  Fractional  Domains 

Fractional-Class  serves  as  a  metaclass  for  types  that  express  a  unitless  fraction.  The  GH  has 
attributes  that  express  percent  completion;  Fractional-Class  is  the  metaclass  for  the  types  of  the 
slots  modeling  those  attributes. 

Fractional-Class  has  three  template  slots.  The  precision  and  digits  slots,  which  are  required,  ex¬ 
press  the  significant  digits  in  the  fraction  as  (decimal)  digits  following  the  decimal  point  and 
total  digits,  respectively.  At  least  one  digit  is  required,  and  the  number  of  digits  must  equal  or 
exceed  the  precision.  Fractions  need  not  be  between  0  and  1 . 

The  third  template  slot,  fractional-class-referenced-class,  expresses  the  class  of  which  a  fraction 
is  being  stated.  This  slot  is  optional. 

Fractional-Class  is  used  to  express  concepts  that  are  not  measurable  things.  Sometimes  this 
merely  means  no  obvious  way  has  been  found  to  measure  something.  For  instance,  the  GH 
data  model  attribute  action-task-status-completion-fraction  is  modeled  as  slot  completionFraction, 
the  type  of  which  is  Task-Completion-Fraction;  the  metaclass  of  Task-Completion-Fraction  is 
Fractional-Class,  and  the  own  slot  value  of  fractional-class-referenced-class  is  Action.  The  intent 
is  to  state  a  completion  fraction  of  an  Action.  An  Action  is  not  a  measurable  thing,  so 
completionFraction  is  not  modeled  as  a  measurement.  Arguably,  “percent  completion”  is  a 
measurable  thing,  and  should  be  expressed  as  such.  But  just  what  it  measures  is  complex. 
Fractional-Class  provides  a  convenient  fallback. 

8.2.4.  Metaclasses  for  Measurable  Domains 

Measurable-Class  is  the  root  of  a  hierarchy  for  describing  types  of  measurable  things  (see 
Figure  9).  Measurable-Class  has  two  template  slots.  Slot  measurable-class-measurable-thing  de¬ 
notes  the  thing  being  measured  by  a  type  whose  metaclass  is  Measurable-Class;  its  value  type 
is  an  instance  of  Measurable-Thing.  Slot  measurable-class-unit-of-measurement  denotes  the  unit 
of  measurement  for  the  measurable  thing.  In  other  words,  a  type  that  uses  Measurable-Class  as 
its  metaclass  explicitly  binds  itself  to  a  measurable  thing  and  a  unit  of  measurement. 
Measurable-Class  is  abstract;  its  subclasses  are  concrete.  It  has  one  direct  subclass  of 
Measurable-Class,  named  Numerically-Measurable-Class.  It  is  intended  for  modeling  types  where 
measurements  are  expressed  as  numbers.  This  encompasses  all  measurements  in  the  GH. 
Numerically-Measurable-Class  has  two  template  slots:  minimum  and  maximum.  These  slots, 
whose  value  types  are  instances  of  Numeric-Expression,  state  the  minimum  and  maximum  val¬ 
ues  allowed  for  a  measurement. 
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Figure  9.  Metaelass  Hierarchy  for  Measurable  Type  Classes 


(Measurable-Class  has  no  other  direct  subclasses.  The  Types  ontology  was  designed  to  allow 
for  non-numeric  measurements,  but  no  need  for  them  has  arisen.) 

Numerically-Measurable-Class  has  a  subclass  named  Numerically-Measurable-Real-Class.  Its  pur¬ 
pose  is  to  model  types  that  state  measurements  as  real  numbers.  It  has  two  template  slots: 
min-inclusive  and  max-inclusive.  These  slots  are  Boolean  valued,  and  describe  whether  the  val¬ 
ues  of  the  minimum  and  maximum  slots,  respectively,  are  to  be  included  in  the  allowed  values 
for  a  measurement  -  that  is,  whether  the  range  is  closed  or  open. 

The  Numerically-Measurable-Decimal-Real-Class  extends  Numerically-Measurable-Class  with  tem¬ 
plate  slots  digits  and  precision  that,  as  for  fractional  classes  (see  Section  8.2.3),  add  informa¬ 
tion  on  significant  digits.  This  metaclass  is  the  one  most  commonly  used  in  the  GH  ontology 
to  model  GH  attributes  that  represent  physical  or  conceptual  properties. 
Numerically-Measurable-Real-Class  is  sometimes  used  for  types  that  model  coded  domains 
mapping  to  measurements.  These  coded  domains  do  not  specify  required  numerical  accuracy 
and  so  cannot  benefit  from  the  additional  slots  of  Numerically-Measurable-Decimal-Real-Class. 
An  example  is  the  type  DS362_nbc_event_spl_siz_code,  which  models  the  size  of  a  spill  of  a 
nuclear,  biological,  or  chemical  (NBC)  weapon.  The  codes  of  this  value  express  some  range 
of  liters  (e.g.,  LARGE  corresponds  to  a  spill  of  between  208  to  1,500  liters,  not  inclusive).  The 
measurable  thing  (liquid  volume)  is  known,  and  its  units  (liters)  are  known,  but  the  precision 
isn’t. 

8.2.5.  Metaclasses  for  Numerically  Describable  Domains 

The  Numerically-Describable-Class  metaclass  is  used  to  characterize  types  for  which  instances 
describe  a  numerical  amount  of  some  class  in  the  ontology.  The  numerical  amount  refers  to  a 
quantity  rather  than  to  a  measurable  thing.  This  metaclass  is  useful  for  an  amount  that  is  not 
enumerable  and  therefore  cannot  be  characterized  as  an  Enumerable-Class.  An  example  from 
the  GH  data  model  is  the  attribute  object-item-capability-quantity. 

Numerically-Describable-Class  has  three  template  slots.  The  digits  and  precision  slots  specify  the 
significant  digits  used  to  state  a  quantity  (see  Section  8.2.3).  The  numerically-describable-class- 
referenced-class  slot  models  the  class  of  which  a  type  is  expressing  some  amount.  For  the  GH 
ontology  class  Capability-Amount,  the  own  slot  value  of  numerically-describable-class-referenced- 
class  is  class  Capability,  that  is,  an  instance  of  Capability-Amount  describes  a  Capability. 
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8.3.  Subclasses  of  the  Type  Class 

The  class  hierarchy  of  types  shown  in  Figure  6  provides  a  basic  categorization  of  types  an 
ontology  might  use.  This  categorization  is  based  on  representation  of  domain  literals.  Aside 
from  a  few  standard  types  that  are  expected  to  be  widely  applicable  and  globally  useful,  the 
subclasses  of  Type  are  abstract.  An  ontology  extends  these  subclasses  to  add  additional  types 
in  support  of  relevant  domains. 

The  following  subsections  discuss  subclasses  in  the  Type  hierarchy.  As  mentioned  on 
page  15,  these  classes  have  no  template  slots  except  for  the  type-instance-value  slot  defined  in 
class  Type.  Subclasses  generally  override  the  value  type  of  the  type-instance-value  slot;  this  is 
discussed  in  each  subsection. 

8.3.1.  Enumerated-Type 

Class  Enumerated-Type  is  the  root  of  classes  whose  members  are  a  finite  enumeration  of  string 
literals.  In  the  GH  ontology,  Enumerated-Type  is  the  root  of  all  types  that  represent  GH’s 
coded  domains. 

The  value  type  of  slot  type-instance-value  is  overridden  to  be  a  set  of  instances  of  Enumerated- 
Element.  A  subclass  of  Enumerated-Type  should  further  override  the  value  type  to  the  subclass 
of  Enumerated-Element  that  is  relevant  for  the  enumeration. 

The  Types  ontology  provides  one  expository  concrete  enumerated  type,  defined  by  class 
Month-Type.  This  type  is  an  enumeration  of  months  of  the  year.  The  value  type  of  its  type- 
instance-value  slot  is  Enumerated-Element-Mapped-Onto-Numeric-Range  (see  Section  8.4.2). 

The  metaclass  of  Month-Type  is  Labeled-Enumerable-Class-Mapping-To-Type  (see  Sec¬ 
tion  8.2.2. 1).  The  class  is  mapped  to  class  Date-Type,  implying  that  any  instance  of  the  class 
must  be  interpreted  as  a  date.  The  class  has  twelve  valid  elements.  Instances  of  Order- 
Specification  establish  the  expected  total  order  among  them. 

8.3.2.  Numeric-Type 

The  Numeric-Type  class  is  the  root  of  all  classes  that  represent  a  numeric  type  (see  Figure  10). 
The  type-instance-value  slot  of  the  class  has  as  its  value  type  a  set  of  instances  of  Numeric- 
Expression.  In  other  words,  evaluating  the  slot  yields  a  numeric  value.  This  value  may  involve 
variables.  The  knowledge  base  provides  a  context  in  which  to  evaluate  a  numeric  expression, 
and  that  context  must  supply  values  for  all  variables  in  an  expression. 

The  metaclass  of  Numeric-Type  is  Type-Class.  This  conveys  no  information  except  that 
Numeric-Type  denotes  a  type. 

Numeric  types  are  further  categorized  as  being  integer  or  real.  It  is  expected  that  a  Numeric- 
Expression  instance  associated  with  the  type-instance-value  slot  of  an  Integral-Type  will  evaluate 
to  an  integer,  and  that  a  Numeric-Expression  instance  associated  with  the  type-instance-value  slot 
of  a  Real-Type  will  evaluate  to  a  real.  Protege-2000  does  not  provide  for  determining  the  type 
of  a  Numeric-Expression  instance,  however. 

The  Integral-Type  and  Real-Type  classes  are  further  specialized  by  abstract  classes  that  catego¬ 
rize  types  according  to  the  origins  of  a  numeric  domain.  Integral  types  are  divided  into: 

1.  Computer-related,  i.e.,  those  that  model  integers  as  represented  on  computers.  The 
Types  ontology  includes  two  concrete  subclasses  of  Integral-Type-Computer-Related:  16- 
bit  signed  integer  and  32-bit  signed  integer.  Both  of  these  classes  have  Integrally- 
Enumerable-Class  as  their  metaclass.  This  allows  them  to  establish  minima  and 
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Figure  10.  Classes  for  Numeric  Types 

maxima.  The  values,  instances  of  Integer-Literal,  are  the  expected  bounds  for  16-  and 
32-bit  signed  values. 

2.  Decimal  domain,  in  which  constraints  on  minima  and  maxima  are  expressed  as  pow¬ 
ers  of  ten.  (This  property  is  characteristic  of  many  GH  data  model  domains,  though 
on  reflection  the  need  for  such  grouping  is  not  strong.)  The  Types  ontology  offers  the 
concrete  class  Year-Class,  which  models  A.D.  years.  The  metaclass  of  Year-Class  is 
Numerically-Measurable-Class.  Its  measurable  thing  is  Time,  its  unit  of  measurement  is 
year,  and  its  minimum  value  is  1  (an  instance  of  Integer-Literal).  Because  Protege-2000 
provides  no  built-in  capability  to  evaluate  numeric  expressions,  the  constraint  that  the 
minimum  or  maximum  value  is  a  power  of  ten  is  not  enforced. 

3.  Domain-independent,  which  is  for  integral  domains  drawn  from  mathematics.  The 
Types  ontology  provides  concrete  classes  integer  and  natural.  Both  use  Integrally- 
Enumerable-Class  as  their  metaclass.  The  integer  class  has  neither  a  minimum  nor  a 
maximum.  The  natural  class  has  a  minimum  of  0  (instance  of  Integer-Literal)  and  no 
maximum. 

Real  types  are  divided  into  the  following  categories: 

1 .  Decimal  types,  in  which  properties  of  the  type  are  expressed  as  a  (digits,  precision) 
pair. 

The  metaclass  of  Real-Type-Decimal  is  Type-Class  rather  than  one  of  its  subclass  with 
digits  and  precision  template  slots,  because  metaclasses  with  these  slots  are  scattered 
throughout  the  Type-Class  hierarchy.  A  subclass  of  Real-Type-Decimal  must  have  a 
metaclass  with  digits  and  precision  template  slots,  and  the  number  of  digits  must  equal 
or  exceed  the  precision. 

The  Types  ontology  specifies  one  concrete  subclass  of  Real-Type-Decimal:  Duration. 
Duration  is  a  Numerically-Measurable-Decimal-Real-Class.  It  measures  Time,  though  its 
unit  of  measurement  is  not  specified.  It  is  given  13  digits,  three  of  which  follow  the 
decimal  point.  This  happens  to  be  convenient  for  modeling  GH  data  model  attributes 
that  describe  duration. 
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2.  Unbounded  types,  in  which  no  constraints  are  imposed  on  the  digits  or  precision.  The 
Types  ontology  provides  one  expository  class,  Radition-Dose,  that  is  a  subclass  of  Real- 
Type-Unbounded.  It  is  a  Numerically-Measurable-Class.  It  measures  Radiation  Dose  in 
centigrays.  Its  minimum  is  0.0  (a  Real-Literal). 

Section  8.2. 2.2  explained  that  the  GH  data  model  describes  a  radiation  dose  as  a  la¬ 
beled  enumeration,  where  each  label  maps  to  a  range.  Ratiation-Dose  is  the  type  under¬ 
lying  that  range. 

3.  Numbers  expressed  in  scientific  notation,  where  digits  and  exponent  magnitude  are 
specified.  Neither  the  Types  ontology  nor  the  GH  ontology  contains  any  types  that  re¬ 
quire  scientific  notation.  It  is  included  for  expository  completeness.  If  a  subclass  of 
Real-Type-Scientific-Notation  were  to  be  created,  a  corresponding  metaclass  would  need 
to  be  added  that  captures  the  parameters  of  the  type. 

8.3.3.  String-Type 

The  String-Type  class  is  the  root  of  all  classes  that  describe  types  whose  contents  are  textual. 
Figure  1 1  shows  the  hierarchy  of  string  types  in  the  Types  ontology. 

9  ©Type A 

©■  (c)  Enumerated-Type  A 
©-  ©  Numeric-Type  A 
9  .c  String-Type A 

9  Cl  String-Type-Varying  A 

(c)  Unformatted  Descriptive  String 
©  String-Type- Fixed* 

Figure  11.  Classes  for  String  Types 

All  types  have  a  textual  representation,  but  subclasses  of  String-Type  are  lexicographically 
ordered.  The  Types  ontology  does  not  allow  specification  of  the  details  of  this  ordering  but 
probably  should  (e.g.,  do  spaces  count?).  It  also  does  not,  and  probably  should,  allow  specifi¬ 
cation  of  the  character  set.  The  GH  uses  ASCII,  and  the  Types  ontology,  being  developed  to 
support  the  GH,  assumes  that  degenerate  case. 

The  metaclass  of  String-Type  is  Textual-Class.  Any  subclass  of  String-Type  must  have  a  meta¬ 
class  that  is  a  subclass  of  Textual-Class. 

The  value  type  of  the  type-instance-value  slot  of  String-Type  is  overridden  to  specify  that  it 
must  contain  a  string.  Protege-2000  does  not  place  any  constraints  on  strings  other  than  those 
imposed  by  the  underlying  Java  implementation.  The  textual-class-string-length  slot  of  the 
metaclass  imposes  a  length  constraint. 

There  are  two  categories  of  string  types:  varying  length  and  fixed  length.  Any  subclass  of 
String-Type-Varying  must  set  the  textual-class-varying  slot  to  true.  Any  subclass  of  String-Type- 
Fixed  must  set  the  textual-class-varying  slot  to  false. 

The  Types  ontology  includes  the  expository  concrete  class  Unformatted  Descriptive  String.  This 
class,  whose  metaclass  is  Unformatted-Textual-Class,  specifies  a  type  that  represents  varying 
length  strings  of  up  to  255  characters.  Instances  of  the  type  are  not  presumed  to  have  any  in¬ 
herent  semantics. 

8.3.4.  Boolean-Type 

Class  Boolean-Type  is  the  superclass  of  all  Boolean  types  that  do  not  express  any  recognizable 
meaning  beyond  truth  and  falsehood.  That  is,  for  such  a  domain,  truth  or  falsehood  has  no 
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implications  for  other  instances  in  a  knowledge  base.  The  type-instance-value  slot’s  value  type 
is  overridden  to  be  an  instance  of  class  Boolean-Expression. 

8.3.5.  Date-Type 

Class  Date-Type  is  the  superclass  of  all  classes  that  represent  dates.  A  date  represents  only 
month,  day,  and  year  (or  a  subset  thereof)  information  -  no  time  information  is  present. 

The  type-instance-value  slot’s  value  type  is  overridden  to  be  a  string.  This  representation  is 
used  because  Protege-2000  does  not  support  date/time  types.  An  application  may  need  to 
parse  the  string  to  use  it  for  inferencing  operations. 

The  Types  ontology  contains  the  expository  class  A.D.  Date,  which  represents  a  type  that 
models  a  month/day/year  combination.  See  Section  8.2. 2.2  for  details  on  Integrally- 
Enumerable-Class,  its  metaclass. 

8.3.6.  Time-Type 

Class  Time-type  is  the  superclass  of  all  classes  that  represent  times.  As  with  class  Date-Type, 
the  type-instance-value  slot’s  value  type  is  overridden  to  be  a  string.  Subclasses  are  free  to  fur¬ 
ther  override  its  value  type  to  a  numeric  value,  or  instance  of  Numeric-Expression,  but  strings 
pennit  forms  such  as  “00:10:20”,  which  may  prove  useful  in  certain  circumstances.  The 
Types  ontology  opts  for  maximum  flexibility. 

The  Types  ontology  contains  the  expository  class  Seconds  Up  to  24  Hours,  which  represents  a 
time  of  day.  Its  metaclass  is  Numerically-Measurble-Class;  it  measures  Time,  using  unit  of 
measurement  second.  It  has  a  minimum  of  0  and  a  maximum  of  86,399;  these  values  are  in¬ 
stances  of  Integer-Literal.  The  implication  is  that  instances  of  this  class  measure  time  precise  to 
one  second,  not  fractions  thereof.  However,  the  class  does  not  explicitly  constrain  instances 
to  integral  values. 

8.3.7.  DateTime-Type 

Class  DateTime-Type  is  the  superclass  of  all  classes  that  represent  moments  in  time  requiring 
more  precision  than  a  single  day.  As  with  class  Date-Type,  the  type-instance-value  slot’s  value 
type  is  overridden  to  be  a  string.  As  with  class  Time-Type,  subclasses  are  free  to  override  this 
value  to  any  type  that  makes  more  sense  in  a  given  context. 

Class  DateTime-Type  is  concrete.  Its  metaclass  is  Numerically-Measurable-Class.  Its  measurable 
thing  is  Time. 

8.4.  Enumerated  Elements 

The  Enumerated-Element  class  is  the  root  of  a  class  hierarchy  wherein  each  class  models  the 
elements  of  an  enumerated  domain.  Except  for  two  expository  classes,  Enumerated-Element 
and  all  its  subclasses  in  the  Types  ontology  are  abstract.  An  ontology  that  uses  Types  is  ex¬ 
pected  to  add,  in  the  appropriate  spot  in  the  hierarchy,  a  subclass  of  Enumerated-Element  that 
denotes  an  individual  domain. 

Once  an  ontology  designer  has  created  a  subclass  and  its  instances,  the  instances  are  by  con¬ 
vention  regarded  as  complete.  No  other  ontology,  knowledge  base,  application,  or  user 
should  create  duplicate  instances  of  the  class.  Instead,  references  to  the  existing  instances 
should  be  made.  This  convention  is  necessitated  by  Protege-2000 ’s  approach  to  implement¬ 
ing  frames.  In  particular,  comparisons  for  equality  based  on  object  references  will  be  false  for 
two  distinct  instances  even  if  those  instances  share  the  same  label.  It  is  therefore  necessary 
for  a  single  set  of  instances  to  exist  for  each  Enumerated-Element  subclass. 
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The  Enumerated-Element  class  hierarchy  is  organized  according  to  how  a  domain  of  enumer¬ 
ated  elements  can  be  mapped  to  elements  of  another  domain.  If  the  elements  cannot  be 
mapped,  the  class  representing  the  domain  should  be  a  direct  subclass  of  Enumerated-Element. 
The  Enumerated-Element  class  has  two  template  slots: 

1.  The  enumerated-element-label  slot  models  the  label  associated  with  an  enumerated  ele¬ 
ment.  It  is  a  string,  and  is  required. 

2.  The  enumerated-element-description  slot  models  a  textual  description  associated  with  an 
enumerated  element.  It  is  a  string,  and  is  optional. 

These  two  slots  model  essential  information  of  the  GH  data  model.  Other  ontologies  may 
want  to  add  template  slots  to  model  such  items  as  the  source  of  an  element  or  a  label  to  be 
used  when  displaying  the  element  to  a  user. 

The  following  are  the  steps  an  ontology  designer  takes  when  modeling  an  enumeration: 

1.  Create  a  subclass  s  of  Enumerated-Type.  It  may  be  worth  noting  that,  in  the  GH  ontology, 
all  subclasses  of  Enumerated-Type  are  direct  subclasses.  However,  an  ontology  designer  is 
free  to  further  categorize  enumerations. 

2.  Choose  a  subclass  of  Enumerable-Class  as  the  metaclass  of  s.  If  the  only  concepts  as¬ 
sociated  with  the  enumeration  are  the  elements  and  perhaps  and  ordering,  the  subclass 
will  be  Labeled-Enumerable-Class. 

3.  Create  a  subclass  e  (direct  or  indirect)  of  Enumerated-Element.  By  convention,  the 
name  of  e  ends  with  “-Elements”.  This  distinguishes  it  from  the  name  of  the  type  to 
which  it  corresponds. 

4.  Create  an  instance  of  e  for  each  element  of  the  enumeration,  supplying  the  label  and, 
optionally,  a  description.  If  e  is  an  indirect  subclass  of  Enumerated-Element,  add  ap¬ 
propriate  mapping  information  to  slots  of  the  instance. 

5.  Override  the  type-instance-value  slot  of  s  such  that  the  value  type  is  “instance  of  e”. 

6.  If  the  metaclass  of  s  is  Labeled-Enumerable-Class  or  a  subclass  thereof: 

1 .  Add  to  the  labeled-enumerable-class-elements  slot  of  5  all  instances  of  e  created 
in  step  4. 

2.  If  the  elements  have  a  partial  or  total  order,  create  instances  of  Order- 
Specification  that  describe  orderings  and  add  them  to  the  labeled-enumerable- 
class-elements-ordering  slot. 

3.  Add  any  mappings  that  might  be  specifiable  via  template  slots  of  subclasses  of 

Labeled-Enumerable-Class. 

Figure  12  shows  the  organization  of  classes  that  represent  elements  of  enumerations.  The  fol¬ 
lowing  subsections  cover  each  subclass. 

8.4.1.  Class  Enumerated- Elemenf-Mapped-Onto- Enumerated- Element 
This  class  models  an  enumeration  in  which  each  element  denotes  an  element  of  another  enu¬ 
meration.  It  has  a  template  slot  enumerated-element-mapping-to-element.  The  value  type  of  this 
slot  is  an  instance  of  Enumerated-Element. 

Class  Enumerated-element-Mapped-Onto-Enumerated-Element  was  introduced  into  the  Types  on¬ 
tology  in  the  expectation  that  some  GH  data  model  coded  domains  might  translate  into  oth¬ 
ers.  It  was,  ultimately,  not  used,  i.e.,  no  subclasses  were  created  during  development  of  the 
GH  ontology. 
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<?  (£)  Enumerated-ElementA 

(c)  Enumerated-Element-Mapped-Onto-Enumerated-ElementA 
<?  (c)  Enumerated-Element-Mapped-Onto-Numeric-Range  A 
ci  Colors-Elements 

<?  (c)  Enumerated-Element-Mapped-Onto-Numeric-Value  A 
(c)  Month-Type-Elements 
(Ci  Enumerated-Element-Mapped-Onto- String  A 
©  Enumerated-Element-Mapped-Onto-Boolean-Value  A 
1  ci  Enumerated-Element-Mapped-Onto-UoM  A 

Figure  12.  The  Enumerated-Element  Class  Hierarchy 

8.4.2.  Class  Enumerated-Element-Mapped-Onto-Numeric-Range 

This  class  models  an  enumeration  in  which  each  element  maps  onto  a  continuous  range  of 
numeric  values.  It  has  four  template  slots.  Slot  enumerated-element-mapped-onto-numeric-range- 
Ib,  whose  value  type  is  an  instance  of  Numeric-Expression,  models  the  lower  bound  of  the 
range.  Slot  enumerated-element-mapped-onto-numeric-range-lb-inclusive,  a  Boolean-valued  slot, 
models  whether  the  lower  bound  of  the  range  is  closed  (true)  or  open  (false).  Slots 
enumerated-element-mapped-onto-numeric-range-ub  and  enumerated-element-mapped-onto-numeric- 
range-ub-inclusive  play  analogous  roles  for  the  upper  bound. 

Class  Enumerated-Element-Mapped-Onto-Numeric-Range  has  one  expository  subclass  in  the 
Types  ontology.  Class  Colors-Elements  models  an  enumeration  of  colors  (red,  blue,  green,  etc.) 
with  each  color  mapped  to  a  frequency  range  in  the  electromagnetic  spectrum.  For  example, 
the  instance  labeled  “Red  Spectral  Range”  has  a  lower  bound  of  450.0  and  an  upper  bound  of 
495.0,  roughly  corresponding  to  the  frequencies  the  human  eye  perceives  as  red.3 
The  Colors  class  declares  the  following  ordering  among  its  elements: 
red  <  orange  <  yellow  <  green  <  blue  <  violet 

This  common  view  of  colors  is  the  opposite  of  the  ordering  imposed  by  wave-length  range, 
as  the  red  spectrum  has  a  longer  wave-length  than  the  orange  spectrum.  Although  some  or¬ 
dering  can  be  inferred  from  mapped  enumerated  elements,  it  is  not  necessarily  correct  to  as¬ 
sume  that  this  ordering  reflects  a  usual  worldview.  To  avoid  ambiguity,  an  ontology  designer 
should  explicitly  specify  an  ordering. 

8.4.3.  Class  Enumerated-Element-Mapped-Onto-Numeric-Value 

This  class  models  an  enumeration  in  which  each  element  maps  to  a  single  numeric  value.  It 
has  a  template  slot  named  enumerated-element-numeric-value-mapping,  the  value  type  of  which 
is  an  instance  of  class  Numeric-Expression.  This  slot  specifies  the  numeric  value  to  which  an 
instance  maps.  The  interpretation  of  that  value  (the  measurable  thing  it  denotes,  for  instance) 
must  come  from  the  enumerated  type  of  which  the  element  is  a  component.  The  slot  is  not 
required  to  have  a  value:  some  enumerations  have  an  “undefined”  value. 

Class  Enumerated-Element-Mapped-Onto-Numeric-Value  has  one  expository  subclass  in  the  Types 
ontology.  Class  Month-Type-Elements  models  an  enumeration  of  the  months  of  the  year.  It 
provides  the  elements  of  class  Month-Type  (see  Section  8.3.5).  Each  element  maps  to  an  in¬ 
stance  of  Integer-Literal:  the  instance  labeled  January  maps  to  1,  the  instance  labeled  February 
maps  to  2,  etc. 


These  values  are  approximations.  Concrete  classes  in  the  Types  ontology  are  expository  and  make  no 
claims  of  accuracy. 
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8.4.4.  Class  Enumerated-Element-Mapped-OntcrString 

This  class  models  an  enumeration  in  which  each  element  maps  to  a  single  string  value.  It  has 
a  template  slot  enumerated-element-mapped-onto-string-value,  the  value  type  of  which  is  a 
string.  The  slot  specifies  the  string  to  which  an  instance  maps. 

This  class  was  originally  intended  to  model  enumerations  in  which  a  label  represents  some 
other  value.  The  GH  ontology  does  not  use  it. 

8.4.5.  Class  Enumerated-Element-Mapped-Onto-BoolearrValue 

This  class  models  an  enumeration  with  two  elements,  one  of  which  corresponds  to  truth  and 
the  other  to  falsehood.  It  has  no  template  slots;  it  is  used  for  categorization.  The  class  of 
which  the  elements  are  instances  should  have  Boolean-Class  as  its  metaclass,  and  must  specify 
which  literal  denotes  truth  and  which  falsehood. 

8.4.6.  Class  Enumerated-Element-Mapped-Onto-UoM 

This  class  models  an  enumeration  in  which  each  element  maps  to  a  unit  of  measurement.  It  is 
used  to  model  GH  data  model  attributes  such  as  capability-unit-of-measure-code.  It  has  a  tem¬ 
plate  slot  enumerated-element-uom,  the  value  type  of  which  is  an  instance  of  class  Unit-of- 
Measurement.  The  implication  is  that  the  instance  denotes  the  specified  unit. 

8.5.  Analysis  of  the  Types  Ontology 

The  Types  ontology  is  designed  to  support  strong  typing,  in  the  belief  that  ontology-based 
inferencing  should  take  care  to  ensure  that  facts  are  compatible.  Even  if  two  GH  data  model 
attributes  have  the  same  representation,  their  values  are  not  necessarily  interchangeable  or 
comparable.  Strong  typing  lets  an  ontology  distinguish  between  the  domains  of  slots  in  cases 
where  a  distinction  is  desirable.  But  there  is  no  hard  and  fast  rule  preventing  comparison  of 
domains. 

Strong  typing  comes  at  a  cost.  The  Types  ontology  adds  a  layer  of  instances  in  order  to  define 
the  value  of  a  slot.  The  approach  has  proven  workable,  but  is  arguably  overkill. 

This  section  presents  some  issues  in  the  design  of  the  Types  ontology.  It  gives  alternate  de¬ 
sign  approaches  that  could  have  been  used,  and  compares  them  to  the  decisions  made  in  the 
Types  ontology.  It  also  points  out  weaknesses  where  no  clear  solution  exists. 

8.5.1.  Symbols  for  Enumerations 

If  “Symbol”  is  specified  as  a  possible  value  type  of  a  Protege-2000  slot,  then  the  application 
designer  can  specify  a  set  of  symbols  (each  given  as  a  string),  and  the  slot  is  restricted  to 
these  strings. 

“Symbol”  could  be  used  as  the  value  type  for  an  enumerated  type  (i.e.,  subclass  of 
Enumerated-Type).  Symbols  for  class  Month-Type  would  include  January,  February,  etc.  This  is 
simpler  than  defining  a  corresponding  subclass  of  Enumerated-Element. 

Using  symbols  has  the  following  drawbacks: 

1 .  No  description  is  associated  with  a  symbol.  Adding  a  description  would  require  creat¬ 
ing  a  separate  class  hierarchy  in  which  instances  of  labels  can  be  related  to  instances 
of  descriptions.  That  approach  would  necessitate  something  akin  to  the  Enumerated- 
Element  hierarchy  anyway. 

2.  Symbols  are  not  ordered.  Although  the  Protege-2000  user  interface  always  lists  sym¬ 
bols  in  the  order  in  which  the  ontology  designer  entered  them,  the  Java  API  method  to 
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retrieve  symbols  returns  an  unordered  collection.  Protege-2000 ’s  designers  do  not 
want  users  to  depend  on  the  order. 

These  are  not  fatal  flaws  that  preclude  symbols  from  being  used.  Rather,  it  is  believed  that 
ordering  of  labels  is  useful  for  a  GH  ontology,  and  that  the  current  structure  is  clearer  than 
mapping  symbols  to  descriptions. 

8.5.2.  Inherent  Semantics  for  Dates  and  Times 

The  Types  ontology  contains  classes  for  dates  and  times.  These  classes  draw  upon  measur¬ 
able  things  and  units  of  measurement  defined  in  other  ontologies. 

For  all  that,  the  classes  in  the  Types  ontology  still  lack  semantic  meaning.  The  ontology  can¬ 
not  be  used  to  make  inferences  about  dates  and  times  (“3  weeks  from  today  is  . . .”). 

This  problem  arises  from  Protege-2000 ’s  lack  of  built-in  support  for  dates  and  times.  If  dates 
and  times  were  primitive  types  in  the  same  way  that  integers  and  strings  are,  one  could  ex¬ 
pect  that  Protege-2000  knowledge  bases  would  provide  better  support  for  reasoning  about 
dates  and  times. 

8.5.3.  Specifying  Type  Using  a  Facet 

The  Types  ontology  is  structured  such  that  the  value  type  of  a  slot  is  an  instance  of  some  sub¬ 
class  of  class  Type.  Another  approach  would  be  to  add  to  each  slot  a  facet  that  specifies  the 
type.  To  achieve  this,  the  class  :STANDARD-SLOT  would  be  extended  with  a  class  that  allows  for 
specification  of  a  metaclass  as  a  standard  facet  of  a  slot  (class  Type-Specifier-Slot  in  Figure 
13).  Each  slot  whose  metaclass  is  set  to  Type-Specifier-Slot  can  then  specify  a  type  to  be  asso¬ 
ciated  with  a  slot. 

Consider  the  GH  data  model  entity  OBJECT-ITEM-CAPABILITY,  which  has  organic  attributes 
capability-quantity  (a  number  of  twelve  decimal  digits  with  three  digits  after  the  decimal  point) 
and  object-item-capability-mission-primacy-code  (a  6-character  string  modeling  a  coded  domain 
with  elements  PRIME,  SCNDRY,  and  THIRD).  The  GH  ontology  currently  models  the  attributes  as 
slots  quantity  and  missionPrimacyCode.  The  value  type  of  the  quantity  slot  is  an  instance  of  class 
Capability-Amount;  the  value  type  of  object-item-capability-mission-primacy-code  is  an  instance  of 
class  DS327_msn_primacy_code.  If  the  GH  ontology  used  the  approach  in  Figure  13,  then  the 
quantity  slot  could  be  specified  as  shown  in  Figure  14.  Note  that  in  this  approach: 

1.  Slot  value  types  are  specified  directly,  rather  than  indirectly  as  instances  of  Type.  In 
Figure  14,  the  value  type  is  Float.  Constraints  on  that  type  come  from  the  Slot-Type 
facet. 

2.  Other  standard  facets,  such  as  Minimum,  can  be  used.  (Note,  however,  that  some  meta¬ 
classes  already  include  information  on  minima  and  maxima.  Inclusion  of  this  infor¬ 
mation  for  a  slot  would  constitute  an  additional  constraint.) 
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Figure  13.  Specifying  Types  Using  a  Facet 

This  approach  has  the  disadvantage  of  requiring  more  complex  naming  conventions  than  are 
currently  used  in  the  GH  ontology.  The  reason  derives  from  two  Protege-2000  restrictions: 

1.  Slot  names  are  global,  i.e.,  two  slots  in  the  same  ontology  cannot  have  the  same 
name. 

2.  A  slot  can  have  one  and  only  one  metaclass. 

If  a  class  needed  a  slot  to  record  quantity  but  wanted  to  record  a  quantity  of  something  other 
than  capability  amount,  it  could  not  use  the  quantity  slot.  The  naming  conventions  used  by  the 
GH  data  model,  in  which  attribute  names  are  prefixed  with  entity  names,  would  suffice. 

8.5.4.  Use  of  the  Numeric-Expression  Class 

The  Types  ontology  encourages  use  of  class  Numeric-Expression  to  model  instances  of  numeric 
values.  Minima  and  maxima,  for  example,  are  modeled  as  numeric  expressions  rather  than 
Protege-2000  numeric  literals. 

This  decision  was  made  in  the  belief  that  many  useful  constants  are  best  expressed  as  formu¬ 
las  rather  than  as  literals  because  the  use  of  a  literal  presumes,  especially  for  a  real  number,  a 
particular  representation.  Representing  sin(45°)  as  0.7070107  states  in  so  many  words  that 
one  is  either  assuming  8  significant  digits  or  an  unspecified  number  of  digits  with  ’7’  as  the 
first  digit  after  the  decimal  point.  The  Numeric-Expression  class  frees  an  ontology  designer 
from  this  sort  of  restriction. 

The  Numeric-Expression  class  has  some  drawbacks.  Most  notably,  Protege-2000  cannot  evalu¬ 
ate  an  instance  of  a  Numeric-Expression.  This  is  of  course  an  advantage  too,  as  the  point  of 
Numeric-Expression  is  requiring  the  ontology  designer  to  specify  a  proper  context  in  which  an 
instance  should  be  evaluated.  An  application  designer  must  interpret  that  context  and  write  an 
evaluator.  This  is,  fortunately,  not  a  difficult  chore. 
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Use  of  numeric  expressions  interferes  with  constraint  writing.  Numeric  expressions  that  deal 
with  mappings  necessarily  involve  variables.  Other  numeric  expressions,  such  as  those  speci¬ 
fying  minima  and  maxima,  should  be  prevented  from  having  free  variables.  Writing  a  con¬ 
straint  to  preclude  free  variables  requires  a  recursive  evaluation  capability,  which  PAL  lacks. 
Use  of  numeric  expressions  requires  some  care.  Two  instances  of  Integer-Literal  whose  value 
slots  are  both  0  will  not,  when  compared  using  Java’s  equals()  method,  be  perceived  as  equal. 
The  equals()  method  tests  object  equivalence,  not  conceptual  equivalence  -  unless  it  is  over¬ 
ridden,  and  Protege-2000 ’s  implementation  of  instances  doesn’t  override  equality  testing  in 
this  way.  Thus  evaluation  of  numeric  expressions  is  necessary  to  test  equality.  Evaluation 

carries  risks  too,  as  round-off  errors  may  arise:  to  a  computer,  /  (l ) 4 - h  f{n)  and 

/(«)- 1 - h  /(l)  are  not  necessarily  equal,  after  all. 

It  is  likely  that  a  production  ontology  would  want  to  avoid  use  of  formulas  other  than  those 
with  bound  variables.  Literals  should  be  preferred. 

9.  The  Generic  Hub  (Version  5)  Ontology 

The  GH  ontology  models  the  entities  defined  in  the  Generic  Hub,  version  5.  Every  GH  data 
model  entity  and  attribute  has  a  counterpart  in  the  GH  ontology. 

Figure  15  gives  an  overview.  It  shows  some  of  the  classes  in  the  ontology.  These  classes  are 
subclasses  of  class  GH-Entity.  GH-Entity  has  both  direct  and  indirect  subclasses.  A  reader  fa¬ 
miliar  with  the  Generic  Hub  will  recognize  variants  of  many  Generic  Hub  elements. 

The  GH  ontology  strives  to  add  meaning  to  GH  data  elements.  Wherever  possible,  it  defines 
conceptual  equivalence  among  elements;  lack  of  definition  should  be  taken  to  imply  lack  of 
conceptual  equivalence.  This  equivalence  is  based  on  concepts  of  the  building  block  ontolo¬ 
gies: 

•  Type  equivalence. 

•  Identification  of  thing  being  modeled  (measurable  or  enumerable). 


Figure  14.  Specification  of  Quantity  Slot  Using  Slot-Type  Facet 
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Figure  15.  GH  Ontology  Classes  (Partial) 


•  Identification  of  units  of  measurement. 

•  Mapping  formulas. 

These  concepts  provide  the  basis  for  building  an  inference  engine  that  could  be  used  to  rea 
son  about  data  in  a  GH  knowledge  base. 

The  Generic  Hub  is  defined  using  the  IDEF1X  model.  Three  basic  rules  were  used  to  trans 
late  the  Generic  Hub  to  an  OKBC-based  ontology: 
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1 .  Each  Generic  Hub  entity  was  translated  to  a  class  in  the  GH  ontology. 

2.  Each  organic  attribute  in  the  Generic  Hub  was  translated  to  a  slot  in  the  GH  ontology. 

3.  Each  relationship  in  the  Generic  Hub  was  translated  to  a  multiple  cardinality  slot  in 
the  GH  ontology. 

That  the  resulting  ontology  is  derived  from  the  Generic  Hub  is  easily  recognizable. 

The  design  of  an  IDEF1X  model  uses  many  of  the  same  considerations  as  the  design  of  an 
object-oriented  model.  In  particular,  both  consider  how  to  encapsulate  data  elements  - 
IDEF1X  by  entity,  object-oriented  by  class.  Some  similarity  between  the  Generic  Hub  and 
the  GH  ontology  is  to  be  expected. 

Nevertheless,  IDEF1X  is  not  equivalent  to  a  frame-based  object-oriented  model.  The  follow¬ 
ing  discusses  the  details  of  translation.  It  presents  strategies  for  adding  expressiveness  to  the 
ontology.  It  also  presents  conflicts  that  arise  due  to  the  differences  between  the  models. 

9.1.  Inheritance 

An  object-oriented  model  has  inheritance.  In  Protege-2000,  a  class  inherits  all  template  slots 
of  its  superclasses. 

IDEF1X  has  subtypes.  Subtypes  are  conceptually  similar  to  inheritance.  However: 

•  A  subtype  does  not  inherit  attributes.  Attributes  of  a  supertype  must  be  retrieved 
through  a  JOIN  operation. 

•  Integrity  constraints  are  needed  in  IDEF1X  to  ensure  that  deleting  a  supertype  deletes 
any  corresponding  subtypes. 

•  A  supertype  must  have  a  discriminator  attribute.  The  discriminator  is  implicit  in  an 
object-oriented  model,  because  a  “type  of’  operator  is  available.  If  the  discriminator 
is  incomplete  -  that  is,  if  there  does  not  exist  an  entity  for  every  possible  value  of  the 
discriminator  -  then  the  “type  of’  operator  is  not  sufficiently  powerful. 

•  The  Generic  Hub  does  not  specify  whether  it  is  legal  to  have  an  instance  of  a  super¬ 
type  that  has  no  corresponding  subtype. 

The  first  two  points  do  not  pose  a  problem  to  the  design  of  an  ontology.  The  third  and  fourth 
require  some  care.  Rules  must  be  established  for  how  the  discriminator  will  be  treated. 

Suppose  es  is  a  subtype  of  e  in  the  Generic  Hub.  The  following  rules  were  used  in  the  design 
of  the  GH  ontology: 

1 .  The  class  denoting  e  is  a  superclass  of  the  class  denoting  es . 

2.  The  class  denoting  e  has  a  slot  modeling  the  discriminator  of  e,  even  if  the  discrimi¬ 
nator  is  complete.  This  rule  results  in  redundant  slots  (the  infonnation  can  be  inferred 
from  the  “type  of’  operator),  but  gives  the  GH  ontology  consistency. 

The  GH  ontology  does  not  use  multiple  inheritance.  No  data  elements  in  the  Generic  Hub 
seem  to  benefit  from  multiple  inheritance. 

The  GH  ontology  introduces  one  class  for  which  there  is  no  corresponding  element  in  the 
Generic  Hub.  This  class  is  named  ObjectTypeEstablishment.  It  is  the  superclass  of  the  two 
kinds  of  establishments  that  exist  in  the  Generic  Hub  (materiel  type  and  organization  type). 
These  establishments  share  attributes  (name  and  effective  date)  and  their  commonality  is  ef¬ 
fectively  modeled  using  an  abstract  superclass. 
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9.2.  Organic  Slots 

Each  slot  in  the  GH  ontology  that  models  an  organic  Generic  Hub  attribute  has  properties 
derived  from  those  of  the  attribute: 

1.  If  the  attribute  is  required,  the  slot  is  required.  (Note  that  Protege-2000  flags  viola¬ 
tions  of  the  “required”  facet  in  its  user  interface  but  is  willing  to  save  an  invalid 
model.  The  user  or  application  is  ultimately  responsible  for  ensuring  model  consis¬ 
tency.) 

2.  The  slot’s  value  type  is  an  instance  of  some  concrete  subclass  of  Type. 

3.  The  slot  has  single  cardinality. 

There  are  some  special  rules  for  specific  type  categories.  The  following  subsections  cover 
them. 

9.2.1.  Organic  Slots  Modeling  Coded  Domains 

If  the  slot  models  a  coded  domain,  its  value  type  is  an  instance  of  some  concrete  subclass  of 
Enumerated-Type.  The  categoryCode  slot  of  class  Action  has  instance  of  DS110_act_cat_code  as 
its  value  type.  The  subcateogoryCode  slot  of  class  Capability  has  instance  of 
DS182_capab_subcat_code  as  its  value  type. 

The  enumerated  types  representing  coded  domains  are  all  direct  subclasses  of 
EnumeratedType.  The  names  for  these  types  are  taken  from  the  Generic  Hub  validation  rules 
for  the  attribute  they  represent.  The  alphanumeric  prefix  of  each  names  helps  a  reader  locate 
a  type. 

The  metaclass  of  a  type  class  modeling  a  coded  domain  is  a  subclass  of  Enumerable-Class. 
Most  of  these  classes  use  Labeled-Enumerable-Class  as  their  metaclass.  A  Labeled-Enumerable- 
Class  notes  only  the  elements  of  the  class,  optionally,  it  may  specify  a  partial  or  total  ordering 
among  elements. 

Slots  denoting  category  codes  use  a  type  whose  metaclass  is  Labeled-Enumerable-Class.  There 
is  no  ordering  among  category  code  elements. 

Orderings  have  been  added  wherever  possible.  The  type  DS106_pers_stat_physical_stat  (the 
physical  status  of  a  person)  ranks  codes  based  on  a  person’s  mobility;  greater  mobility  is 
highest.  Thus  IN  (incapacitated,  moveable  by  stretcher)  is  less  than  IW  (incapacitated,  cannot 
perform  tasks  but  can  walk),  which  is  less  than  SI  (incapacitated,  can  perform  tasks),  which  is 
less  than  FT  (fit). 

Some  types  specify  a  partial  rather  than  a  total  order.  The  elements  of 
DS166_unit_type_size_code  cover  Army,  Navy,  and  Air  Force  designations  for  units.  The  or¬ 
dering  for  this  type  includes  the  usual  Army  terms  (squad  <  platoon  <  company  <  ...);  how¬ 
ever,  neither  a  fleet  nor  a  flight  is  directly  comparable.4  Moreover,  the  type  includes  elements 
such  as  TSKEL  (“a  unit  organized  for  a  specific  task”)  whose  size  depends  on  context.  These 
elements  are  omitted  from  the  ordering.  Many  types  have  elements  NKN  (not  known)  and 
NOS  (not  otherwise  specified)  that  likewise  cannot  participate  in  an  ordering. 

Where  possible,  types  modeling  coded  domains  use  a  metaclass  more  descriptive  than 
Labeled-Enumerable-Class.  Examples  include: 


4  The  ordering  specifications  for  DS166_unit_type_size_code  type  are  known  to  be  incomplete  in  the  current 
version  of  the  GH  ontology. 
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•  Action  resource  criticality  indicator  (DS225_act_res_crticality_ind),  whose  two  values 
are  NO  and  YES.  Its  metaclass  is  Boolean-Class. 

•  Presence  of  mines  (DS313_mine_prsnc_code),  whose  three  values  are  NO,  YES,  and 
NKN.  Its  metaclass  is  Tri-State-Class. 

•  Timing  precision  code  (DS284_timing_precision_code),  whose  values  are  SECOND, 
MINUTE,  HR,  DAY,  etc.  Its  metaclass  is  Labeled-Enumerable-Class-Mapping-To- 
Measurement;  the  measurable  thing  is  Time.  No  unit  of  measurement  is  specified,  be¬ 
cause  the  value  is  the  unit  of  measurement. 

There  are  cases  where  different  metaclasses  might  have  been  used.  Consider  materiel-status- 
usage-status-code  (DS259_mat_stat_usage_stat_code),  which  denotes  the  usage  of  a  specific 
materiel.  Its  possible  values  are  ACTIVE  (performing  the  function  for  which  it  is  designed), 
DEACTV  (not  performing  the  function  for  which  it  is  designed),  and  NKN  (not  known).  This 
class’s  metaclass  could  be  Tri-State-Class,  where  ACTIVE  corresponds  to  truth,  DEACTV  to 
falsehood,  and  NKN  to  an  undefined  value.  The  conceptual  difficulty  of  this  approach  is  that 
the  ontology  does  not  link  truth  to  anything,  as  it  has  no  implications  concerning  the  meaning 
of  active  materiel. 

Each  enumerated  type  is  linked  via  its  elements  to  a  subclass  of  Enumerated-Element  (see 
Figure  12).  Each  of  classes  is  instantiated  with  all  instances  of  the  coded  domain  it  models. 
The  slots  of  the  class  let  both  the  code  and  a  description  be  stated.  The  GH  ontology  contains 
all  the  codes  in  the  Generic  Hub.  This,  as  discussed  in  Section  8.4,  facilitates  comparison. 

The  classes  denoting  the  enumerated  elements  are  divided  among  the  Enumerated-Element 
class  hierarchy.  Classes  in  this  tree  add  slots  according  to  meaning.  Instances  of  classes  mod¬ 
eling  Generic  Hub  coded  domains  must  give  values  for  as  many  slots  as  possible. 

Most  enumerated  element  classes  in  the  GH  ontology  are  direct  subclasses  of  Enumerated- 
Element.  All  these  classes  have  :STANDARD-CLASS  as  their  metaclass.  In  other  words,  any  se¬ 
mantics  related  to  an  enumeration  are  expressed  as  part  of  the  type  or  as  part  of  an  instance, 
not  as  part  of  an  element’s  class. 

9.2.2.  Organic  Slots  Modeling  Dates  and  Times 

The  Generic  Hub  contains  several  attributes  that  model  dates  and  times.  These  elements  are 
stored  as  strings.  A  date  is  an  eight  character  string  of  the  form  YYYYMMDD.  If  DD  is 
“00”,  the  date  is  precise  only  to  within  one  month.  If  MM  and  DD  are  both  “00”,  the  date  is 
precise  only  to  within  one  year. 

A  time  is  stored  as  a  six  character  string  of  the  form  HHMMSS.  Times  are  always  precise  to 
within  one  second. 

The  GH  ontology  models  dates  and  times  using  the  types  A.D.  Date  and  Seconds  Up  To  24 
Hours,  respectively.  The  implication  is  that  any  two  slots  of  value  type  A.D.  Date  may  be  com¬ 
pared,  as  may  any  two  slots  of  value  type  Seconds  Up  To  24  Hours. 

The  type-instance-value  slot  of  A.D.  Date  stores  a  string.  The  format  of  this  string  is  identical  to 
that  used  in  the  Generic  Hub. 

The  type-instance-value  slot  of  Seconds  Up  To  24  Hours  stores  an  integer.  Metaclass  constraints 
restrict  this  integer  to  between  0  and  86,399,  inclusive.  Note  that  translating  between  a  Ge¬ 
neric  Hub  data  set  and  a  GH  knowledge  base  requires  conversion  of  times. 


A-36 


9.3.  Relationships 

The  Generic  Hub  uses  two  kinds  of  relationships:  one-to-many  and  many-to-many.  All 
many-to-many  relationships  have  an  associative  entity. 

9.3.1.  One-to-Many  Relationships 

Modeling  one-to-many  relationships  in  Protege-2000  is  straightforward.  For  each  Generic 
Hub  one-to-many  relationship  r  from  entity  A  to  entity  B,  the  GH  ontology  associates  with 
the  class  modeling  A  (Ca)  a  slot  that  models  r.  This  slot  has  multiple  cardinality.  Its  value 
type  is  instance  of  the  class  modeling  B  (Cb). 

Given  an  instance  of  Ca,  it’s  easy  to  use  Protege-2000  to  find  all  associated  instances  of  Cb, 
through  both  the  user  interface  and  the  Java  API.  Given  an  instance  of  Cb,  it’s  harder  to  find 
the  associated  instance  of  Ca.  In  Java,  one  can  find  the  instance  using  a  simple,  if  time- 
consuming,  algorithm.  A  Protege-2000  user  must  perform  a  tedious  search  using  internal  in¬ 
stance  names. 

The  GH  ontology  always  defines  an  inverse  slot  for  each  one-to-many  relationship.  The  slot 
in  Ca  that  models  r  has  an  inverse  slot  associated  with  Cb.  This  slot  is  required  only  if  the  cor¬ 
responding  foreign  key  of  B  is  required.  Its  value  type  is  a  single  instance  of  Ca.  Because 
many-to-many  relationships  are  modeled  as  two  one-to-many  relationships  (see  below),  in¬ 
verse  slots  also  exist  for  many-to-many  relationships. 

9.3.2.  Many-to-Many  Relationships 

Protege-2000  supports  many-to-many  relationships  only  if  they  don’t  have  an  associative  en¬ 
tity.  Unfortunately,  this  excludes  all  many-to-many  relationships  in  the  Generic  Hub. 

A  few  associative  entities  have  no  attributes  other  than  their  keys  (e.g.,  ACTION-TASK-RULE-OF- 
ENGAGEMENT).  These  entities  could  be  omitted  from  the  GH  ontology,  but  a  solution  is  needed 
for  modeling  the  rest  of  the  associative  entities. 

There  are  two  possible  approaches  to  modeling  many-to-many  relationships  in  Protege-2000. 
The  first  is  to  mimic  the  structure  of  the  Generic  Hub.  Suppose  the  Generic  hub  defines  a 
many-to-many  relationship  between  entities  E\  and  ZG  with  associative  entity  Ea.  Let  C\,  C2, 
and  Ca  be  the  classes  that  model  E\,  ZG,  and  Ea,  respectively.  Let  Ci  and  C2,  have  slots  r\  and 
r2  that  define  a  one-to-many  relationship  to  Ca  (plus  inverse  slots  for  Ca,  as  noted  above).  The 
set  of  all  instances  of  C2  associated  with  an  instance  of  Ci  is  the  instance  of  the  inverse  of  r2 
of  the  set  of  all  instances  of  Ca  associated  with  C 1  through  r\. 

This  approach  is  reasonable  if  one  does  not  mind  the  indirection  necessitated  by  the  imposi¬ 
tion  of  Ca  between  C\  and  C2.  A  second  approach  to  modeling  many-to-many  relationships  is 
to  treat  them  as  first-class  objects.  The  GH  ontology  could  contain  a  class  MNRelationships 
with  the  following  template  slots: 

•  instA,  which  defines  the  instance  of  C\  that  participates  in  the  relationship.  Its  value 
type  would  be  an  instance  of  a  GH  class. 

•  instB,  which  defines  the  instance  of  C2  that  participates  in  the  relationship.  Its  value 
type  would  be  an  instance  of  a  GH  class. 

•  associativelnst,  which  defines  the  instance  of  Ca  that  participates  in  the  relationship. 

The  value  type  of  all  of  these  slots  is  an  instance  of  a  GH  class.  All  slots  are  required. 

This  second  approach  simplifies  the  task  of  finding  the  set  of  all  instances  of  C2  associated 
with  instance  c\  of  C\  and  vice  versa.  One  issues  a  query  of  the  form: 


A-37 


Find  all  instances  of  MNRelationships  where  the  class  of  instA  is  Cj,  the  class  of  instB  is  C2, 
the  class  of  associativelnst  is  Ca,  and  the  value  of  instA  is  c\. 

This  approach  has  the  following  drawbacks: 

1.  The  MNRelationships  class  will  have  a  large  number  of  instances.  Searching  it  may  be¬ 
come  time-consuming. 

2.  Certain  infonnation  on  many-to-many  relationships  vanishes  from  the  ontology.  The 
name  of  a  relationship,  which  can  be  captured  in  a  slot,  is  lost.  This  may  hinder  col¬ 
lection  and  dissemination  of  metadata. 

3.  An  associative  entity  must  participate  in  exactly  one  instance  of  a  relationship.  This  is 
automatically  enforced  using  the  first  approach,  but  it’s  possible  to  add  an  instance  to 
MNRelationships  in  violation  of  this  constraint. 

These  drawbacks  have  workarounds.  For  instance,  rather  than  defining  a  single  class 
MNRelationships,  the  GH  ontology  could  define  a  separate  class  for  each  many-to-many  rela¬ 
tionship.  Own  slot  of  such  classes  could  specify  metadata. 

The  GH  ontology  uses  the  first  approach.  It  relies  on  a  model  that  is  known  to  be  workable 
and  can  be  regarded  as  the  cautious  option.  It  is  also  more  explicit  about  showing  relation¬ 
ships  between  classes,  which  is  probably  an  advantage  when  defining  metadata. 

9.3.3.  Associative  Classes 

Each  class  that  models  a  Generic  Hub  associative  entity  has  metaclass  Associative-Class.  An 
Associative-Class  explicitly  specifies  the  two  entities  involved  in  the  association.  The  class  has 
two  template  slots,  associative-class-class-1  and  associative-class-class-2.  Both  are  required,  and 
both  have  a  class  that  is  a  subclass  of  GH-Entity  as  their  value  type.  This  extra  infonnation 
may  prove  useful  in  disambiguating  associations.  Figure  16  shows  the  specification  of  class 
ObjectltemType,  the  class  associated  with  the  many-to-many  relationship  between  Objectltem 
and  ObjectType. 

Associative  classes  used  to  play  an  important  role  when  an  application  loaded  a  GH  knowl¬ 
edge  base.  Subsequent  changes  in  implementation  techniques  have  obviated  the  need  for 
them.  They  are  currently  retained  in  the  belief  that  specific  knowledge  of  the  role  a  class 
plays  may  be  useful. 

9.4.  Absence  of  Keys 

The  GH  ontology  does  not  have  any  slots  that  model  values  of  Generic  Hub  key  attributes, 
either  primary  or  foreign.  A  knowledge  base  does  not  need  such  slots;  each  instance  in  an 
object  model  has  a  unique  name  that  is  assigned  at  the  time  the  instance  is  created.  This  name 
obviates  the  need  for  primary  keys. 

Translating  a  Generic  Hub  data  set  into  a  GH  knowledge  base  requires  translating  foreign 
keys  into  slot  value  instances.  Updating  a  Generic  Hub  data  set  with  changes  from  a  GH 
knowledge  base  requires  knowledge  of  the  keys  associated  with  the  data  used  to  create  an 
instance.  Annex  B  presents  one  approach  to  implementing  this  functionality. 

9.5.  Naming  Conventions 

Elements  in  the  Generic  Hub  follow  certain  naming  conventions  that  are  suited  to  a  DBMS 
but  not  necessarily  elsewhere.  The  GH  ontology  was  created  with  the  expectation  that  the 
contents  of  a  knowledge  base  might  need  to  be  shared  among  applications.  Specifically: 
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851  Object  ItemType  (type = Associative-Class) 
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Figure  16.  The  Specification  of  the  ObjectltemType  Class 

1 .  Names  should  be  meaningful.  The  physical  model  of  the  Generic  Hub  uses  valid  SQL 
names  such  as  ACT  and  GEO  FEAT.  If  class  names  in  an  ontology  are  to  serve  as  meta¬ 
data,  they  should  be  composed  of  actual  words,  not  abbreviations. 

2.  Names  should  adhere  to  conventions  of  programming  languages.  One  way  to  share 
knowledge  among  application  is  through  XML,  using  a  data  model  such  as  DTD  or 
XSD.  These  models  have  rules  for  names  and  their  transformation  into  Java  identifi¬ 
ers. 

9.5.1.  Naming  Conventions  for  GH-Entity  Subclass  Elements 

In  the  GH  ontology,  names  are  closer  to  those  in  the  Generic  Hub  logical  model  than  the 

physical  model: 

1 .  Class  names  are  taken  from  entity  names.  The  upper  case  names  are  converted  to  ini¬ 
tial  upper  case,  and  hyphens  are  removed. 

2.  Organic  slot  names  are  derived  from  attribute  names.  In  the  Generic  Hub,  an  attrib¬ 
ute’s  name  is  prefixed  with  the  name  of  the  entity  to  which  it  belongs.  In  the  GH  on¬ 
tology,  a  slot’s  name  is  formed  by  removing  the  entity’s  name,  then  concatenating  the 
separate  words  of  the  attribute’s  name  (removing  the  hyphens)  with  each  word  other 
than  the  first  converted  to  initial  upper  case.  For  example,  the  attribute  reporting-data- 
timing-category-code  within  the  GH  entity  reporting-data  becomes  timingCategoryCode. 

3.  Slot  names  for  one-to-many  relationships  are  derived  from  the  relationship  phrase  and 
the  name  of  the  associated  class.  Words  in  the  phrase  are  in  lower  case  and  are  sepa¬ 
rated  by  hyphens;  also,  a  hyphen  separates  the  phrase  from  the  associated  class  name. 
For  example,  class  Objectltem  has  slots  named  has-ObjectltemStatus  and  is-specified-with- 
ObjectltemCapability. 

4.  Inverse  slot  names  are  constructed  from  three  parts:  the  name  of  the  (physical)  table 
implementing  the  entity  at  the  “many”  end  of  the  relationship,  the  inverse  phrase,  and 


ObjectltemType 


Role 

Concrete 
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the  name  of  the  class  at  the  “one”  end  of  the  relationship.  For  example,  the  inverse  of 
has-ObjectltemStatus  is  obj_item_status-is-ascribed-to-Objectltem. 

The  table  name  must  be  prefixed  to  the  slot  name  to  avoid  conflicts.  In  particular,  the 
Generic  Hub  has  fourteen  relationships  of  the  fonn  “REPORTING-DATA  provides  applica¬ 
tion  information  for  E”  each  of  which  has  an  inverse  relationship  “E  is  referenced  to 
REPORTING-DATA”.  A  slot  can  have  at  most  one  inverse;  thus  the  inverse  slot  imple¬ 
menting  the  inverse  relationship  can’t  be  shared  by  the  fourteen  relationships  of 
REPORTING-DATA.  Prefixing  the  slot  name  with  the  table  name  makes  the  slot  name 
unique.  (On  reflection,  the  ontology  would  have  been  more  readable  if  the  class  name 
had  been  used  instead  of  the  table  name.) 

These  naming  conventions  result  in  shorter  (and  therefore  simpler)  names  than  in  the  Generic 
Hub.  They  do,  however,  yield  conflicts.  Attributes  action-name,  object-item-name,  and  object- 
type-name  are  all  modeled  in  the  GH  ontology  as  a  slot  named  name.  None  of  these  slots 
shares  the  same  value  type;  all  are  instances  of  a  different  subclass  of  String-Type.  Protege- 
2000  permits  slot  facets  to  be  overridden  on  a  per-class  basis,  which  allows  the  different 
value  types  to  be  specified.  Some  care  is  needed  when  viewing  and  modifying  slots,  how¬ 
ever,  as  it  is  easy  to  accidentally  view  a  slot’s  global  rather  than  local  definition. 

Slots  named  categoryCode  have  a  more  interesting  conflict.  Entities  OBJECT-TYPE,  MATERIEL- 
TYPE,  CONSUMABLE-MATERIEL-TYPE,  and  AMMUNITION-TYPE  all  have  a  (distinctly  named)  category 
code  attribute;  these  attributes  all  translate  into  slots  named  categoryCode.  The  issue  is  not  the 
common  name,  but  rather  that  the  classes  representing  these  entities  are  part  of  an  inheritance 
hierarchy.  If  class  Cs  is  a  subclass  of  C,  Protege-2000  only  displays  the  union  of  the  template 
slots  of  Cs  as  determined  by  name.  If  Cs  overrides  a  property  of  some  template  slot  of  C,  Pro¬ 
tege-2000  lets  the  user  see  the  slot  only  with  the  overridden  properties.  The  slot  as  it  appears 
in  C  is  invisible.  In  other  words,  for  an  instance  of  AmmunitionType  a  user  may  set  the 
categoryCode  slot  to  a  valid  ammunition  type  but  cannot  set  the  categoryCode  slot  of  any  other 
class  in  the  hierarchy. 

One  fix  would  be  to  use  the  Generic  Hub’s  naming  conventions.  Instead,  the  GH  ontology 
relies  on  the  fact  that  the  category  code  of  a  superclass  can  always  be  inferred.  Given  an  in¬ 
stance  of  AmmunitionType,  the  category  code  for  class  ConsumableMaterielType  must  be  AMMO, 
the  category  code  for  class  MaterielType  must  be  CM,  and  so  on.  No  information  is  lost.  In 
fact,  one  can  argue  that  including  all  the  category  codes  under  different  names  merely  per¬ 
mits  errors  in  the  ontology.  Deriving  category  codes  from  the  class  hierarchy  is  safer. 

Generic  Hub  discriminator  attributes  that  are  incomplete  must  also  be  considered.  For  exam¬ 
ple,  the  facility-category-code  attribute  has  seven  values,  but  for  two  -  NOS  and  ROADWY  - 
there  is  no  corresponding  subtype  entity.  For  such  values,  an  instance  of  Facility  must  be  a  di¬ 
rect  instance.  This  rule  can  be  enforced  with  a  PAL  constraint: 

(defrange  ?f  :FRAME  Facility) 

(forall  ?f 

(=>  (or  (=  (enumerated-element-label  (type-instance-value  (categoryCode  ?f)  “NOS”) 

(=  (enumerated-element-label  (type-instance-value  (categoryCode  ?f)  “ROADWY”)) 
(direct-instance-of  ?f  Facility) 

In  fact,  rules  related  to  the  value  of  the  categoryCode  slot  for  the  Facility  class  can  be  stated 
using  PAL: 
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(defrange  ?f  :FRAME  Facility) 

(forall  ?f 

(and  (=>  (direct-instance-of  ?f  Airfield) 

(=  (enumerated-element-label  (type-instance-value  (categoryCode  ?f)))  "AIRFLD")) 

(=>  (direct-instance-of  ?f  Bridge) 

(=  (enumerated-element-label  (type-instance-value  (categoryCode  ?f)))  "BRIDGE")) 

(=>  (direct-instance-of  ?f  MassGrave) 

(=  (enumerated-element-label  (type-instance-value  (categoryCode  ?f)))  "MSSGRV")) 

(=>  (direct-instance-of  ?f  Minefield) 

(=  (enumerated-element-label  (type-instance-value  (categoryCode  ?f)))  "MINE")) 

(=>  (or  (=  (enumerated-element-label  (type-instance-value  (categoryCode  ?f)))  "NOS") 

(=  (enumerated-element-label  (type-instance-value  (categoryCode  ?f)))  "ROADWY")) 

(direct-instance-of  ?f  Facility)))) 

This  constraint  does  not  include  a  test  for  the  NETWRK  value  because,  of  all  subclasses  of 
Facility,  only  class  Network  has  its  own  definition  of  slot  categoryCode. 

9.5.2.  Naming  Conventions  for  Types 

The  types  used  in  the  GH  ontology  -  that  is,  the  subclasses  of  Type  -  also  follow  naming 
conventions: 

1.  Names  of  types  derived  from  coded  domains  are  taken  from  validation  rules  in  the 
Generic  Hub.  For  instance,  the  name  of  the  type  for  the  categoryCode  attribute  of  the 
Action  class  is  DS110_act_cat_code. 

2.  Other  type  names  are  derived  from  the  attribute  they  model.  Examples  include  Bridge- 
Spans,  Holding-Quantity,  and  Capability-Amount.  Capability-Amount  is  the  value  type  of  the 
quantity  slots  of  both  ObjectltemCapability  and  ObjectTypeCapabilityNorm.  The  generic 
name  reflects  its  shared  use. 

These  two  conventions  are  not  consistent,  and  should  be  resolved.  During  the  design  of  the 
ontology,  the  use  of  the  validation  rule  name  facilitated  cross-referencing.  Now  that  the  on¬ 
tology  is  complete,  it  would  be  better  to  use  a  more  meaningful  name,  perhaps  retaining  the 
validation  rule  name  through  the  use  of  a  metaclass. 

The  convention  for  other  type  names  is  inconsistent  with  the  conventions  used  for  class 
names.  Hyphens  should  be  used  consistently. 

10.  The  Command  and  Control  (C2)  Ontology 

The  C2  ontology  differs  from  the  ontologies  upon  which  it  is  built.  The  difference  stems 
from  the  intent  of  how  the  ontology  will  be  populated: 

•  The  ontologies  underlying  the  GH  ontology  are  intended  to  be  pre-populated  with 
concepts  relevant  to  modeling  physical  and  conceptual  properties  of  C2  data.  This  in¬ 
formation,  then,  is  fixed. 

•  The  GH  ontology  is  intended  to  be  populated  in  real  time  with  instances  obtained 
from  sensor  and  network  data  -  in  other  words,  from  infonnation  drawn  from  GH- 
conformant  data  sets.  A  GH  ontology  must  be  continually  updated  with  the  latest  in¬ 
formation  on  battlefield  object  location,  status,  supply,  plans,  etc.  This  information  ul¬ 
timately  derives  from  observations. 
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•  By  contrast,  the  C2  ontology  is  intended  to  be  populated  by  information  drawn  from 
reasoning.  This  information  is  likely  to  be  generated  by  an  inferencing  engine  (see  be¬ 
low)  though  there  is  no  inherent  reason  it  cannot  be  entered  manually. 

Whereas  the  GH  ontology  contains  atomic  C2  data,  the  C2  ontology  contains  high-level  ab¬ 
stract  notions  of  command  and  control.  The  C2  ontology  intends  to  capture  the  abstract  con¬ 
cepts  that  warfighters  use  as  part  of  reasoning  during  the  decision-making  process. 

Whereas  the  GH  and  underlying  ontologies  are  useable  and  close  to  production  quality,  the 
C2  ontology  is  preliminary.  Identification,  formalization,  and  incorporation  of  a  useful  set  of 
abstract  warfighting  concepts  is  a  huge,  multi-year  task  (one  way  to  grasp  its  magnitude  is  to 
think  of  formalizing  doctrine).  The  purpose  of  the  C2  ontology  to  date  has  been  to  study  how 
concepts  can  be  formalized,  thereby  providing  a  framework  for  an  eventual  effort. 

The  size  and  complexity  of  the  overall  task  dictated  that  the  “framework”  ontology  would 
need  to  concentrate  on  some  subset  of  C2.  Two  areas  were  selected:  threats  and  organization 
operational  readiness.  Both  are  regarded  as  complex  but  vital  in  C2.  Their  successful  formal¬ 
ization  in  an  ontology  would  provide  a  convincing  demonstration  of  certain  vital  net-centric 
precepts. 

Even  the  formalization  of  these  two  areas  -  indeed,  of  either  one  -  is  a  task  of  considerable 
complexity.  The  C2  ontology  in  its  current  state  covers  only  threats,  and  does  not  claim  to 
have  an  adequate  formulation  of  that  concept.  Whether  the  subjective  notion  of  “threat”  can 
ever  be  formalized  is  still  an  open  question.  And  whether  a  GH-conformant  data  set  (or,  cor¬ 
respondingly,  a  GH  ontology)  provides  enough  information  to  identify  all  conceivable  threats 
is  still  unknown. 

10.1.  Classes  of  the  C2  Ontology 

The  C2  ontology  adds  a  single  class  hierarchy  to  the  underlying  ontologies.  This  hierarchy  is 
rooted  by  a  class  named  Threat,  which  is  a  subclass  of  THING.  Threat  is  an  abstract  class  com¬ 
prising  subclasses  that,  as  one  descends  deeper  into  the  hierarchy,  specialize  the  kind  of 
threat  in  terms  of  the  OBJECT-ITEM  posing  the  threat  and  the  OBJECT-ITEM  being  threatened.  Only 
leaf  notes  of  the  hierarchy  are  concrete  classes.  The  C2  ontology  currently  recognizes  threats 
posed  by  organizations  and  persons,  and  threats  to  facilities,  organizations,  and  persons.  See 
Figure  17. 

9  ©Threat* 

9  C' Organisation-Threat A 

(c)  Organisation-Threat-To-Facility 
(c)  Organisation-Threat-To-Organisation 
(c)  Organisation-Threat-To-Person 
9  ©'  Person-Threat* 

(c)  Person-Threat-To-Facility 
(c)  Person-Threat-To-Organisation 
(c)  Person-Threat-To-Person 

Figure  17.  C2  Ontology  Classes 

10.2.  Slots  of  the  C2  Ontology 

The  C2  ontology  defines  two  slots.  Both  are  template  slots  of  class  Threat: 

1 .  The  threatening-object-item  slot  denotes  the  object  item  that  poses  a  threat. 

2.  The  threatened-object-item  slot  denotes  the  object  item  that  is  threatened. 
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The  value  type  of  both  of  these  slots  is  an  instance  of  class  Objectltem.  Slots  in  the  C2  ontol¬ 
ogy  build  on  properties  defined  in  the  underlying  ontologies.  The  C2  ontology  states  that 
threats  are  posed  by  battlefield  objects,  that  battlefield  objects  may  be  threatened,  and  that  a 
threat  is  a  binary  relationship  between  two  battlefield  objects.5 

The  C2  ontology  defines  PAL  constraints  that  specialize  these  slots  according  to  their  place¬ 
ment  in  the  hierarchy.  Class  Organisation-Threat  has  a  constraint  that  requires  the  value  of  the 
threatening-object-item  to  be  an  instance  of  class  Organisation,  whereas  Class  Person-Threat  has  a 
constraint  that  requires  the  value  of  the  threatening-object-item  to  be  an  instance  of  class  Per¬ 
son.  Classes  Organisation-Threat-To-Facility  and  Person-Threat-To-Facility  both  require  the 
threatened-object-item  slot’s  value  to  be  an  instance  of  Facility.  These  constraints  are  straight¬ 
forward  to  express;  for  example, 

(defrange  ?ot  :FRAME  Organisation-Threat) 

(forall  ?ot 

(instance-of  (threatening-object-item  ?ot)  Organisation)) 

states  that  in  every  instance  of  Organisation-Threat  the  OBJECT-ITEM  posing  the  threat  must  be  an 
instance  of  an  ORGANISATION. 

The  Threat  class  has  a  more  complex  PAL  constraint  that  requires  the  threatening  OBJECT-ITEM 
to  be  hostile  according  to  its  most  recent  OBJECT-ITEM-STATUS.  This  constraint  is  worth  present¬ 
ing  as  an  illustration  of  the  complexity  that  constraint  writers  are  likely  to  encounter: 

(defrange  ?status  :FRAME  ObjectltemStatus  has-ObjectltemStatus) 

(defrange  ?hc  :FRAME  DS145_obj_item_stat_hstly_code) 

(defrange  ?hce  : FRAME  DS145_obj_item_stat_hstly_code-Elements) 

(defrange  ?statp  :FRAME  ObjectltemStatus  has-ObjectltemStatus) 

(defrange  ?rd  :FRAME  ReportingData) 

(defrange  ?rdp  :FRAME  ReportingData) 

(defrange  ?dt  :FRAME  Date-Type) 

(defrange  ?dtp  :FRAME  Date-Type) 

(defrange  ?tm  :FRAME  Time-Type) 

(defrange  ?tmp  :FRAME  Time-Type) 

(defrange  ?t  :FRAME  Threat) 

(forall  ?t  (exists  ?status  (and  (has-ObjectltemStatus  (threatening-object-item  ?t)  ?status) 

(exists  ?hc  (and  (hostilityCode  ?status  ?hc) 

(exists  ?hce  (and  (type-instance-value  ?hc  ?hce) 

(enumerated-element-label  ?hce  "FIO") 

(exists  ?rd  (and  (provides-applicable-information-for-ObjectltemStatus  ?rd  ?status) 

(not  (exists  ?statp  (and  (has-ObjectltemStatus  (threatening-object-item  ?t)  ?statp) 

(exists  ?rdp  (and  (provides-applicable-information-for-ObjectltemStatus  ?rdp  ?statp) 
(exists  ?dt  (and  (reportingDate  ?rd  ?dt) 

(exists  ?tm  (and  (reportingTime  ?rd  ?tm) 

(exists  ?dtp  (and  (reportingDate  ?rdp  ?dtp) 

(exists  ?tmp  (and  (reportingTime  ?rdp  ?tmp) 


5  A  more  realistic  definition  of  a  threat  is  a  binary  relationship  between  two  sets  of  battlefield  objects,  but  the 
complexity  of  that  relationship  introduces  details  that  are  beyond  the  experimental  nature  of  the  C2  ontol¬ 
ogy.  Here  and  elsewhere,  however,  this  section  notes  such  simplifications. 
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(=>  (=  ?dt  ?dtp)  (>  ?tmp  ?tm)) 

(>  ?dtp  ?dt))))))))))))))))))))))) 

The  complexity  of  this  constraint  -  which,  as  discussed  below,  is  incomplete  -  is  attributable 
to  at  least  three  factors: 

1.  The  lack  of  user-defined  functions  in  PAL.  Procedural  abstractions  would  eliminate 
common  subexpressions  (note  the  repeated  occurrences  of  (has-ObjectltemStatus  ...). 

2.  The  difficulty  of  expressing  ordering  relationships  in  a  set-theoretic  language.  The 
expression  that  constrains  an  instance  of  ObjectltemStatus  to  the  most  recent  with  re¬ 
spect  to  all  other  instances  associated  with  an  Objectltem  is  easy  enough  to  state:  there 
does  not  exist  another  instance  whose  reporting  date  is  greater,  or  whose  reporting 
date  is  equal  and  whose  time  is  greater.  But  expressing  it  in  PAL  requires  introducing 
an  extra  set  of  variables  bound  to  Re  porting  Data,  Date-Type,  and  Time-Type.  If  instead 
one  could  write  an  expression  denoting  the  last  instance  of  the  sorted  ObjectltemStatus 
instances,  the  above  expression  would  be  considerably  simpler.  Unfortunately,  sets 
aren’t  ordered,  so  most  set-theoretic  languages  don’t  include  operators  that  take  ad¬ 
vantage  of  order. 

3.  The  representation  decisions  in  the  Type  ontology.  Section  8.5  discussed  the  advan¬ 
tages  and  disadvantages  of  the  type-instance-value  slot  and  the  Enumerated-Element 
class.  The  above  expression  shows  how  they  add  to  the  complexity  of  a  PAL  con¬ 
straint. 

Study  of  the  constraint  statement  shows  that  it  is  deciding  which  ObjectltemStatus  is  most  re¬ 
cent  based  on  the  reportingDate  and  reportingTime  slots  of  the  associated  ReportingData  instance. 
This  raises  three  issues: 

1.  The  constraint  assumes  a  GH  knowledge  base  is  valid.  The  GH  ontology  requires  an 
ObjectltemStatus  instance  to  be  associated  with  a  ReportingData  instance.  The  constraint 
doesn’t  check  to  ensure  if  the  association  exists.  PAL  permits  such  a  test  (using  its 
own-slot-not-null  predicate);  it  has  been  omitted  for  simplicity. 

2.  Slot  reportingDate  is  required;  reportingTime  is  not.  The  constraint  needs  to  test  whether 
reportingTime  is  null.  Moreover,  the  ontology  designers  need  an  accepted  definition  of 
the  meaning  of  order  for  comparing  two  ReportingData  instances  where  one’s 
reportingTime  slot  is  null  and  the  other’s  is  not. 

3.  Arguably,  the  comparison  should  be  based  on  effective  rather  than  reported  timing. 
An  effective  timing  specification  derives  from  either  the  effectiveDate  and  effectives  me 
template  slots  of  subclass  ReportingDataAbsoluteTiming  or  from  the  offsetDuration  tem¬ 
plate  slot  of  subclass  ReportingDataRelativeTiming  added  to  the  plannedStartDate  and 
plannedStartTime  slots.  PAL  can  differentiate  between  subclasses.  It  lacks  date  arith¬ 
metic  operators,  however. 

In  other  words,  the  constraint  is  incomplete,  and  completing  it  would  greatly  increase  its 
complexity. 

10.3.  Uses  of  the  C2  Ontology 

The  C2  ontology  is  intended  to  be  used  in  a  rule-based  inferencing  environment.  Applica¬ 
tions  will  query  a  C2  knowledge  base,  either  periodically  or  on  demand  (or  both).  The  que¬ 
ries  will  be  predefined,  and  will  be  a  specification  of  how  command  and  control  information 
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may  be  derived  from  the  information  in  a  GH  knowledge  base  (or,  more  likely,  a  C2  knowl¬ 
edge  base,  as  rules  may  rely  on  previously  derived  C2  information). 

For  example,  an  organization  O  might  ask:6 

(Threat  :threatened-object-item  0  :threatening-object-item  ?x) 

The  result  of  this  query  is  a  set  consisting  of  all  Organisation  and  Person  instances  in  the 
knowledge  base  that  pose  a  threat  to  O  according  to  rules  in  the  C2  ontology. 

Alternately,  an  application  may  opt  to  add  a  new  fact  to  a  knowledge  base  directly.  This 
would  happen  if  the  application  had  certain  knowledge  of  the  existence  of  a  threat.  It  would 
tell  the  knowledge  base: 

(Organisation-Threat-To-Organisation  :threatened-object-item  0  :threatening-object-item  T) 
thereby  creating  a  new  instance  of  class  Organisation-Threat-To-Organisation. 

Ask  and  tell  are  inferencing  terminology.  When  an  application  “tells”  a  knowledge  base  of  a 
fact,  rules  stored  in  the  knowledge  base  may  be  automatically  triggered  that  add  additional 
facts;  this  is  known  as  forward  chaining.  When  an  application  “asks”  a  knowledge  base  a 
query,  rules  may  also  be  automatically  triggered  that  add  additional  facts;  this  is  known  as 
backward  chaining. 

Chaining  helps  populate  knowledge  bases.  It  adds  information  based  on  rules  that  ontology 
designers  fonnulate.  Note  that  arbitrary  infonnation  is  not  preserved,  i.e.,  intermediate  com¬ 
putations  of  a  query  are  not  necessarily  saved.  Instead,  rule  designers  define  the  concepts  that 
a  query  reveals. 

10.3.1.  Backward  Chaining 

Backward  chaining  ensures  that  information  generated  as  a  result  of  a  query  is  preserved.  A 
query  is  stated  as  an  application  of  a  template  slot  to  an  instance.  For  instance, 

((instance  Unit  ?u)  (has-ObjectltemStatus  ?u  ?status)) 
poses  the  query  “find  all  instances  of  ObjectltemStatus  that  are  related  to  an  instance  of  Unit.” 
It  assigns  the  results  of  the  query  to  the  variable  ?status. 

Backward  chaining  provides  rules  for  answering  queries.  In  the  C2  ontology,  an  obvious 
query  is: 

Find  all  threats  to  the  unit  whose  name  is  N. 

The  query  is  posed  as: 

((instance  Unit  ?u  (name  ?u  N) 

(threatened-object-item  ?threat-inst  ?u) 

(threatening-object-item  ?threat-inst  ?threatener)) 

The  issue  is  how  one  determines  the  existence  of  a  threat  -  that  is,  how  instances  of  class 
Threat  are  created.  Unless  those  instances  exist,  the  query  will  fail. 

A  C2  knowledge  base  might  be  populated  with  instances  of  Threat  in  three  ways: 

1 .  A  user  can  manually  add  instances. 


6  The  syntax  is  taken  from  the  Semantic  Language  (SL)  of  the  Federation  for  Intelligent  Physical  Agents 
(FIPA).  SL  is  intended  for  stating  queries  and  their  results. 
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2.  An  application  can  scan  the  knowledge  base  looking  for  facts  that  justify  creating  an 
instance  of  Threat.  This  scanning  might  occur  periodically  or  each  time  new  facts  are 
added  (or  both). 

3.  An  application-  or  user- initiated  query  that  detects  a  threat  can  automatically  create 
an  instance  of  Threat. 

Backward  chaining  rules  implement  the  third  strategy.  Backward  chaining  is  expressed  as  a 
rule  of  the  form: 

(consequent  <-  antecedent) 

Whenever  a  query  or  one  of  its  clauses  matches  the  consequent  of  a  backward  chaining  rule, 
the  antecedent  is  automatically  applied  to  see  if  it  generates  instances;  if  it  does,  those  in¬ 
stances  are  asserted  as  new  facts  in  the  knowledge  base.  The  canonical  example  is: 

((aunt  ?person  ?y)  <r  (parent  ?person  ?x)  (sister  ?x  ?y)) 
that  is,  when  one  poses  a  query  to  find  the  aunts  of  some  person,  the  approach  to  answering 
that  query  is  to  search  for  the  person’s  parents,  then  search  for  the  parents’  sisters. 

For  the  C2  ontology,  a  logical  backward  chaining  rule  would  be: 

(threatened-object-item  ?threat-inst  ?obj-item)  <-  ( rules  defining  threat )) 

That  is,  any  time  a  query  is  posed  to  determine  whether  an  Objectltem  instance  is  threatened, 
the  query  is  answered  by  invoking  the  rules  defining  the  concept  of  a  threat.  For  each  suc¬ 
cessful  application  of  these  rules  -  that  is,  for  each  threatened  Objectltem  instance  found  -the 
threatened-object-item  slot  of  a  Threat  subclass  instance  is  set  to  the  threatened  instance. 

This  simple  explanation  omits  certain  details,  in  particular  the  rules  defining  a  threat.  An¬ 
nex  B  presents  more  detail  on  how  this  would  be  achieved.  Even  so,  it  is  not  the  intent  of  ei¬ 
ther  annex  to  present  a  realistic  definition.  That  would  result  from  an  intense  study  of  how 
C2  could  be  formalized  using  Generic  Hub  concepts.  Such  a  study  is  beyond  the  scope  of  this 
document. 

10.3.2.  Forward  Chaining 

Forward  chaining  is  used  to  maintain  invariant  relationships  and  knowledge  base  consis¬ 
tency.  A  traditional  use  of  forward  chaining  is  to  maintain  inverse  relationships.  Given  the 
rule: 

((parent  ?a  ?b)  ->  (child  ?b  ?a)) 

then  whenever  an  application  asserts  that  a  is  the  parent  of  b,  the  knowledge  base  also  notes 
that  b  is  the  child  of  a.  The  GH  ontology  does  not  need  this  sort  of  rule;  its  use  of  Protege- 
2000’s  inverse  slot  feature  ensures  Protege-2000  will  automatically  add  an  inverse  relation¬ 
ship. 

There  are,  however,  more  sophisticated  uses  of  forward  chaining,  and  the  C2  ontology  could 
benefit  from  them.  For  example,  an  application  cannot  just  tell  a  knowledge  base  of  the  exis¬ 
tence  of  a  threat.  The  knowledge  base  needs  to  know  who  believes  the  threat  exists,  and  why. 
Forward  chaining  rules  can  be  used  to  gather,  generate,  and  add  this  additional  infonnation, 
in  the  form  of  GH  ontology  instances,  to  a  C2  knowledge  base.  A  rule  of  the  form: 
((threatened-object-item  ?threat  ?ol)  (threatening-object-item  ?o2)  -> 

( Add  relevant  GH  instances  to  knowledge  base)) 
ensures  this  will  happen  whenever  someone  sets  the  slots  of  a  Threat. 
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Annex  B:  Design  of  a  Net-Centric  System 
Using  the  GH  Ontology 

This  annex  presents  the  design  of  a  simulation  prototype  decision  support  system  that  uses 
the  GH  ontology  described  in  Annex  A.  The  prototype  explores  how  decision  support  func¬ 
tionality  can  be  implemented  in  a  net-centric  environment.  This  annex  also  is  intended  to 
provide  a  canonical  architecture  for  implementing  decision  support  in  that  environment. 

The  purpose  of  this  annex  is  to  discuss  design  and  implementation  decisions  and  details  that 
arose  during  the  prototype’s  construction.  This  annex  should  help  organizations  intending  to 
implement  applications,  particularly  decision  support  applications,  in  a  net-centric  environ¬ 
ment,  as  they  will  face  many  of  the  issues  encountered  building  this  prototype.  The  informa¬ 
tion  in  this  annex  is  meant  to  provide  guidance. 

A  prototype  system  is  not  a  production  system.  Some  design  decisions  in  a  prototype  are 
made  to  reduce  effort  in  order  to  get  the  system  running  quickly.  Generally,  therefore,  proto¬ 
types: 

•  Incorporate  technology-specific  functionality  at  the  expense  of  flexibility  and  easy 
maintainability. 

•  Use  algorithms  whose  execution  time  is  acceptable  only  for  small  data  sets. 

•  Make  simplifying  assumptions  on  error  handling. 

The  prototype  developed  in  this  study  has  these  features.  They  are  noted,  along  with  discus¬ 
sion  of  realistic  alternatives. 

The  IDA  prototype  uses  several  freely  available  technologies  and  implementations.  They  are 
discussed  briefly  in  Section  3.1,  but  this  annex  is  not  intended  to  explicate  them.  The  reader 
may  need  to  refer  to  supplementary  documentation  to  fully  understand  some  of  the  technical 
discussion.  Also,  some  illustrations  assume  familiarity  with  the  Unified  Modeling  Language. 

1.  Operational  View 

The  prototype  system’s  operational  view  strives  to  provide  a  simple  but  realistic  (if  abstract) 
simulation  of  roles  humans  play  in  a  warfighting  environment.  The  prototype  currently  fo¬ 
cuses  on  a  single  human  role,  namely,  that  of  the  decision  maker.  It  is  assumed  that  a  deci¬ 
sion  maker  will  act  on  information  available  within  the  net-centric  environment.  Within  the 
IDA  prototype  the  characteristics  of  decision  makers  is  predefined.  Once  the  prototype  starts 
executing,  roles  do  not  change. 

The  IDA  team  also  modeled  decision  making  as  hierarchical,  recognizing  command  chains. 
A  higher  level  decision  maker  has  authorities  not  granted  to  a  lower  level  decision  maker. 

The  prototype  is  organized  around  military  units.  A  unit  is  either  friendly  or  hostile.  Friendly 
units  are  able  to  communicate  with  each  other. 

A  friendly  unit  has  a  set  of  associated  decision  makers.  Decision  support  functionality  pre¬ 
sents  decision  makers  with  threats.  (The  definition  of  a  threat  is  complicated,  and  is  taken  up 
repeatedly  in  this  annex;  informally,  it  means  the  movement  of  a  hostile  organization  toward 
a  friendly  organization.)  The  objective  of  decision  makers  is  to  determine  and  enter  appropri¬ 
ate  responses  to  threats.  The  prototype  currently  only  allows  decision  makers  to  enter  these 
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responses  -  i.e.,  the  simulation  does  not  evolve  beyond  the  first  stage.  Specifically,  this 
means  that  their  associated  friendly  units  do  not  fire,  move,  or  otherwise  take  physical  action. 

Each  decision  maker  sees  a  specific  portion  of  the  battle  space.  His  information  on  the  battle 
space  comes  from  intelligence  sources  controlled  by  his  unit  and  communications  from  other 
units.  He  is  responsible  for  communicating  to  other  friendly  units  all  infonnation  newly  ob¬ 
tained  from  his  intelligence  sources. 

The  operational  architecture  deliberately  omits  a  role  for  infonnation  analysts.  It  is  assumed 
that  the  delivery  of  infonnation  traditionally  supplied  by  human  analysts  is  the  responsibility 
of  the  network  centric  system. 

The  prototype  also  includes  support  roles.  Individuals  playing  these  roles  act  as  controllers: 

•  An  individual  may  control  a  hostile  (enemy)  organization.  The  role  of  an  enemy  or¬ 
ganization  in  the  prototype  is  to  move;  as  it  moves,  it  can  be  detected  by  an  intelli¬ 
gence  source  connected  to  a  friendly  organization.  The  controller  of  an  enemy  or¬ 
ganization  specifies  whether  it  is  currently  moving,  and  if  so,  its  speed  and  bearing 
angle.  Simulations  work  with  discrete  events,  so  the  controller  also  specifies  the  posi¬ 
tion  refresh  rate,  which  is  how  often  the  component  implementing  an  enemy  organi¬ 
zation  recalculates  its  position. 

•  An  individual  may  control  the  initiation  and  tennination  of  the  prototype’s  execution. 
This  is  an  administrative  role.  The  administrator  specifies  the  number  of  friendly  and 
enemy  organizations  that  will  participate  in  a  simulation,  as  well  as  the  inclusion  or 
exclusion  of  some  supporting  components.  Once  the  prototype  is  executing,  the  ad¬ 
ministrator  has  the  option  of  instructing  all  enemy  organizations  to  start  or  stop.  In 
other  words,  the  administrator  can  assume  the  role  of  enemy  organization  controller. 

Figure  1  depicts  the  operational  view.  The  emphasis  is  on  the  roles  active  during  execution; 
the  administrator  is  omitted.  Intelligence  sources  (shown  as  humans,  but  possibly  mechanical 
or  electronic  sensors)  operate  within  a  battle  space  to  obtain  information  of  use  to  decision 
makers.  This  information  is  transmitted  to  intercommunicating  decision  support  applications, 
which  in  turn  present  information  to  decision  makers.  The  role  of  the  decision  support  appli¬ 
cations  is  to  filter  and  select  the  information  presented  to  decision  makers.  This  ensures  that 
decision  makers  have  the  best  pertinent  information  available.  They  make  decisions  and  feed 
them  back  into  the  decision  support  applications,  which  in  turn  update  each  other  with  the 
latest  information  on  friendly  organization  state  and  intentions. 
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2.  System  View 

The  system  view  shows  the  system  decomposed  into  its  component  subsystems.  It  presents 
the  interconnections  between  these  subsystems.  It  also  shows  the  interactions  of  external 
components  (humans  and  external  computer  systems). 

Figure  2  shows  the  high-level  system  view  after  initialization.  There  exists: 

•  A  set  of  subsystems  implementing  friendly  organizations.  Each  friendly  organization 
has  an  associated  set  of  decision  makers,  an  associated  set  of  intelligence  sources,  and 
a  location. 

•  A  set  of  subsystems  implementing  enemy  (hostile)  organizations.  Each  enemy  or- 
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ganization  has  a  current  location,  speed,  and  bearing  angle. 

•  An  overview  subsystem.  This  component  presents  a  two-dimensional  display  of  the 
location  of  every  known  organization,  both  friendly  and  hostile.  It  is  used  as  an  aid  by 
administrators. 

•  A  simulation  state  subsystem.  This  subsystem  maintains  ground  truth.  Each  subsys¬ 
tem  that  may  change  a  component  of  its  ground  truth  is  responsible  for  communicat¬ 
ing  the  change  to  the  simulation  state  subsystem.  Arrows  in  Figure  2  connected  to 
SimState  show  how  ground  truth  is  obtained  and  communicated: 

•  Each  time  an  enemy  organization  changes  its  location,  it  sends  that  new  loca¬ 
tion  to  the  SimState  component. 

•  A  friendly  organization  periodically  requests  the  SimState  component  to  send 
the  latest  information  on  properties  (such  as  location)  of  battlefield  objects. 
This  simulates  humans  making  observations. 

•  The  SimState  component  sends  ground  truth  updates  to  the  overview  compo¬ 
nent.  (Note  that  a  friendly  organization  pulls  data,  whereas  the  overview  com¬ 
ponent  receives  pushed  data.) 

•  A  set  of  database  management  subsystems.  Each  DBMS  maintains  a  GH- 
conformant  data  set  accessed  by  some  set  of  friendly  organizations.  Each 
friendly  organization  accesses  exactly  one  DBMS. 

An  execution  of  an  interacting  set  of  these  subsystems  is  termed  a  simulation.  Each  simula¬ 
tion  must  have  at  least  one  Friendly  Organization,  at  least  one  DBMS,  and  exactly  one  Sim¬ 
State.  Other  components  are  optional.  Their  inclusion  follows  from  the  objectives  of  a  simu¬ 
lation. 

Friendly  organizations  communicate  with  each  other.  Enemy  organizations  currently  do  not. 
This  reflects  the  prototype’s  focus  on  decision  support  between  friendly  organizations. 

The  system  view  does  not  prescribe  any  hardware  configurations  beyond  those  needed  to  im¬ 
plement  the  system  software.  The  simulation  may  be  run  on  one  or  many  different  com¬ 
puters.  If  multiple  computers  are  used,  they  must  be  connected  by  a  network  that  supports 
TCP/IP. 

The  GH-conformant  data  sets  need  not  be  identical  at  the  time  the  prototype  components  start 
executing.  Differing  data  sets  will  cause  individual  components  to  have  differing  views  of  the 
battle  space,  which  of  course  typifies  warfighting,  and  is  also  what  warfighters  seek  to  avoid. 
One  goal  of  the  prototype  is  to  ensure  that  views  converge.  However,  data  is  pulled  rather 
than  pushed  in  a  net-centric  environment,  so  convergence  cannot  be  mandated  as  it  might  in 
current  operational  environments.  It  must  instead  be  incorporated  in  more  subtle  ways. 

2.1.  Enemy  Organizations 

An  enemy  organization  (also  known  as  a  hostile  organization)  is  a  semi-autonomous  entity. 
Its  controller  may  set  it  in  motion.  Once  moving  it  may  be  halted. 

An  enemy  organization  is  identified  by  its  name.  An  enemy  organization  must  be  defined  in 
the  GH-conformant  data  set  at  the  time  the  simulation  begins.  Specifically,  the  following  in¬ 
formation  must  exist:1 


1  For  readability,  names  are  taken  from  GH’s  logical  rather  than  physical  model. 
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Figure  3.  Enemy  Organization  User  Interface 

•  The  OBJECT-ITEM  table  must  have  exactly  one  row  whose  object-item-name  column  is 
that  of  the  enemy  organization. 

•  The  ORGANISATION  table  must  have  a  row  whose  key  is  that  of  the  aforementioned  row 
in  the  OBJECT-ITEM  table. 

•  The  OBJECT-ITEM-LOCATION  table  must  have  at  least  one  row  linked  to  the  OBJECT-ITEM 
table  via  the  object-item-id  portion  of  the  key.  If  more  than  one  row  in  OBJECT-ITEM- 
LOCATION  maps  to  the  OBJECT-ITEM,  then  the  relevant  row  is  the  one  that  is  most  recent 
according  to  the  reporting  date  and  time  of  its  associated  REPORTING-DATA. 

•  The  row  in  the  LOCATION  table  that  maps  to  the  aforementioned  row  in  OBJECT-ITEM- 
LOCATION  must  be  an  instance  of  a  POINT.  That  is,  its  location-category-code  column  must 
have  the  value  'PT',  and  there  must  exist  a  corresponding  row  in  the  POINT  table. 

•  The  row  in  the  POINT  table  must  be  fully  specified  as  either  an  ABSOLUTE-POINT  or  a 
RELATIVE-POINT.  If  it  is  a  RELATIVE-POINT,  it  must  be  resolvable  into  an  ABSOLUTE-POINT. 

An  enemy  organization  has  five  attributes:  current  location,  bearing  angle,  speed,  whether  it 
is  moving,  and  refresh  rate.  The  first  three  attributes  are  initially  taken  from  information  in 
the  Generic  Hub  data  set.  Bearing  angle,  speed,  and  refresh  rate  may  also  be  provided  at  the 
time  the  enemy  organization  is  initialized;  initialization-time  values  will  override  any  in  the 
data  set.  These  values  are  all  shown  in  the  user  interface  of  an  enemy  organization  (Figure  3). 
Bearing  angle,  speed,  and  position  refresh  rate  must  all  be  specified  before  an  enemy  organi¬ 
zation  can  move. 

The  movement  state  of  an  enemy  organization  is  dynamically  controlled,  either  by  a  human 
or  by  the  Loader  subsystem.  When  an  organization  starts  moving,  it  begins  recalculating  its 
position.  Periodically,  as  specified  by  the  refresh  rate  (in  seconds),  it  computes  the  position  it 
would  have  if  it  were  to  move  at  the  specified  bearing  angle  and  speed.  It  updates  its  display 
of  position,  and  sends  this  new  position  to  the  SimState  system. 

Any  time  an  enemy  organization  is  not  moving,  its  controller  may  change  its  bearing  angle, 
speed,  and  position  refresh  rate.  Organization  name  is  immutable.  An  enemy  organization  is 
not  permitted  to  morph  into  another. 

On  start-up,  an  enemy  organization  has  the  following  parameters: 

1 .  The  URL  of  a  GH  ontology. 
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Figure  4.  Overview  of  Friendly  Organization  Behavior 

2.  The  URL  of  a  Generic  Hub  data  set.  This  parameter  is  optional;  if  not  given,  the  en¬ 
emy  organization  uses  a  canned  set  of  data. 

3.  The  name  of  the  organization.  This  name  must  exist  in  the  Generic  Hub  data  set. 

4.  Initial  values  for  bearing  angle  and  speed.  These  parameters  are  optional.  If  not  given, 
the  values  are  undefined. 

5.  An  initial  value,  in  seconds,  for  the  position  refresh  rate,  the  interval  between  times 
when  the  enemy  organization  is  to  recalculate  its  position  based  on  speed  and  bearing 
angle.  This  parameter  is  optional.  If  not  given,  the  position  refresh  rate  is  undefined. 

6.  Whether  the  enemy  organization  is  to  have  a  visible  user  interface  on  the  computer 
where  it  is  initiated.  This  parameter  is  optional.  If  not  given,  the  enemy  organization 
will  have  a  visible  user  interface. 

7.  A  name  that  is  unique  with  respect  to  names  of  all  other  system  components  that  will 
execute  on  the  computer  running  the  enemy  organization. 

2.2.  Friendly  Organizations 

Friendly  organizations  are  the  emphasis  of  the  prototype,  as  its  purpose  is  to  explore  how  on¬ 
tologies  can  be  used  to  automate  decision  support  functions.  Each  friendly  organization,  then, 
is  provided  with  decision  support  functionality.  Figure  4  delineates  a  friendly  organization’s 
behavior  using  a  sequence  diagram.  A  decision  maker  has  a  decision  support  application. 
This  application  has  access  to  a  GH  knowledge  base.  Periodically,  the  decision  support  ap¬ 
plication  analyzes  the  knowledge  base  using  rules  that  detect  the  presence  of  threats.  If  it 
finds  none,  it  repeats  the  analysis  after  a  prespecified  interval. 
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When  the  decision  support  application  determines  that  a  threat  exists,  it  notifies  the  decision 
maker,  then  presents  to  the  decision  maker  a  set  of  courses  of  action  that  seem  reasonable  in 
light  of  the  threat.  The  decision  maker  chooses  one  (or  none),  and  the  decision  support  appli¬ 
cation  responds  appropriately  (Figure  4  does  not  elaborate  this  aspect).  Meanwhile,  the  deci¬ 
sion  support  application  schedules  another  threat  analysis. 

Each  friendly  organization  must  exist  in  the  Generic  Hub  data  set  being  used  at  the  time  its 
subsystem  is  initialized.  Specifically,  the  following  information  must  exist: 

•  The  OBJECT-ITEM  table  must  have  exactly  one  row  whose  object-item-name  column  is 
that  of  the  friendly  organization. 

•  The  ORGANISATION  table  must  have  a  row  whose  key  is  that  of  the  aforementioned  row 
in  the  OBJECT-ITEM  table. 

•  The  OBJECT-ITEM-LOCATION  table  must  have  at  least  one  row  linked  to  the  OBJECT-ITEM 
table  via  the  object-item-id  portion  of  the  key.  If  more  than  one  row  in  OBJECT-ITEM- 
LOCATION  maps  to  the  OBJECT-ITEM,  then  the  relevant  row  is  the  one  that  is  most  recent 
according  to  the  reporting  date  and  time  of  its  associated  REPORTING-DATA. 

•  The  row  in  the  LOCATION  table  that  maps  to  the  aforementioned  row  in  OBJECT-ITEM- 
LOCATION  must  be  an  instance  of  a  POINT.  That  is,  its  location-category-code  column  must 
have  the  value  'PT',  and  there  must  exist  a  corresponding  row  in  the  POINT  table. 

•  The  row  in  the  POINT  table  must  be  fully  specified  as  either  an  ABSOLUTE-POINT  or  a 
RELATIVE-POINT.  If  it  is  a  RELATIVE-POINT,  it  must  be  resolvable  into  an  ABSOLUTE-POINT. 

A  decision  support  system  must  present  its  user  with  the  best  possible  information  for  mak¬ 
ing  decisions.  The  emphasis  of  this  implementation  is  currently  on  detecting  hostile  organiza¬ 
tions  and  making  decisions  on  how  to  respond  to  their  presence.  The  user  interface  of  a 
friendly  organization  therefore  shows  its  users  a  map  of  that  portion  of  the  battle  space  occu¬ 
pied  by  the  organization,  plus  subsidiary  infonnation  on  supplies  and  threats  (see  Figure  5). 
Organizations  on  the  map  are  shown  as  “red”  and  “blue”  units.  Red  units  are  hostile.  Blue 
units  are  friendly.  The  friendly  organization  controlling  the  map  is  the  one  whose  “U”  is 
darker  than  the  others  (in  Figure  5,  the  rightmost  unit). 

The  map  provides  a  visual  clue  on  imminence  of  threats.  The  decision  makers  see  the  move¬ 
ment  of  a  hostile  organization  in  real  time.  Its  vector  helps  detennine  whether  it  presents  a 
direct  threat  to  any  friendly  organization. 

The  interface  should  not  be  taken  as  a  recommendation  on  information  to  include  interfaces 
of  automated  decision  support  applications;  it  is  simply  information  that  is  useful  in  interpret¬ 
ing  the  results  of  the  prototype  simulation  as  it  executes. 

Information  other  than  the  map  displayed  by  the  decision  support  system  is  as  follows: 

•  The  window’s  title  bar  shows  the  organization’s  name. 

•  The  lower  left  table  shows  the  organization’s  holdings  of  battlefield  object  types  (ma¬ 
teriel,  persons,  and  other  organizations).  Holdings  are  derived  from  rows  of  the  GH 
table  HOLDING  associated  with  the  organization.  The  quantity  column  is  derived  from 
the  holding-total-quantity  column  of  the  Generic  Hub.  (The  prototype  does  not  currently 
distinguish  between  total  and  operational  holdings.) 

•  Threats  to  the  organization  appear  on  the  right  side  as  a  list  of  names  of  hostile  or¬ 
ganizations.  Figure  5  shows  one  such  organization,  named  “3C  Armor  Recce  Coy”. 
Note  that  the  list  is  headed  by  the  word  “Yes”,  in  red,  which  aids  in  recognition  of  a 
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Figure  5.  Friendly  Organization  Main  User  Interface 

situation  that  needs  attention.  If  there  are  no  detected  threats,  the  list  is  headed  by 
“No”,  in  black. 

The  user  may  select  a  threat  in  the  list  and  click  the  View  button  below  to  see  details 
on  a  threat  that  may  aid  decision  makers  (Figure  6).  Currently  the  information  is  de¬ 
rived  from  the  estimated  time  until  the  hostile  organization  reaches  the  friendly  or¬ 
ganization’s  location,  assuming  the  hostile  organization  continues  at  its  current  bear¬ 
ing  angle  and  speed.  A  more  sophisticated  decision  support  system  would  incorporate 
terrain  and  weaponry  into  the  analysis. 


Figure  6.  Example  Threat  Details 

•  The  area  in  the  lower  right  shows  C4I  information  generated  and  received  from  other 
friendly  organizations.  As  part  of  decision  making,  a  friendly  organization  may  for¬ 
mulate  tasks  (expressed  as  rows  in  the  ACTION-TASK  table  plus  rows  in  associated  ta- 
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bles).  Its  current  (i.e.,  most  recent)  task  is  displayed  in  the  Most  Recent  Task  field. 
Furthermore,  a  friendly  organization  sends  infonnation  it  formulates  to  other  friendly 
organizations  and,  conversely,  receives  updates  from  these  organizations.  These  up¬ 
dates  eventually  translate  into  updates  to  a  friendly  organization’s  knowledge  base. 
They  are  displayed  in  the  KB  Updates  area. 

•  One  possible  update  is  a  new  task  received  from  a  commanding  organization.  Such  an 
update  is  displayed  in  both  the  Most  Recent  Task  field  and  the  KB  Updates  area.  In 
the  Most  Recent  Task  area,  it  summarizes  the  friendly  organization’s  current  objec¬ 
tive.  In  the  KB  Updates  area,  it  shows  the  friendly  organization’s  communications 
with  other  friendly  organizations. 

•  The  Most  Recent  Task  field  provides  information  that  may  be  useful  in  formulating  a 
decision;  for  example,  whether  the  current  task  can  be  overridden.  The  KB  Updates 
area  is  mainly  gives  a  sense  that  the  system  is  functioning  correctly  in  that  it  is  gener¬ 
ating  and  receiving  infonnation.  It  would  probably  be  of  little  value  in  a  real  decision 
support  application. 

Friendly  organizations  send  updates  to  the  knowledge  base  using  Generic  Hub  elements. 
That  is,  when  one  friendly  organization  wants  to  notify  others  of  updates,  it  sends  a  message 
containing  a  set  of  Generic  Hub  table  rows.  This  is  one  of  three  possible  formats.  The  other 
two  are: 

1 .  Use  a  custom  message  format. 

2.  Use  elements  in  the  GH  ontology. 

Using  Generic  Hub  elements  seems  most  logical.  The  Generic  Hub  is  an  accepted  standard. 
Devising  any  custom  format  would  entail  work  that  would  probably  duplicate  effort  already 
put  into  the  Generic  Hub.  The  approach  using  elements  of  the  GH  ontology  has  some  merit, 
but  it  uniquely  identifies  an  instance  by  frame  name,  which  is  application  specific,  as  op¬ 
posed  to  Generic  Hub  keys,  which  can  be  considered  more  readily  interoperable,  by,  for  ex¬ 
ample,  implementing  an  RDBMS  key  management  that  ensures  global  uniqueness  within  the 
entire  operational  environment.  The  only  difficulty  with  using  Generic  Hub  elements  is  the 
difficulty  of  translating  between  the  knowledge  base  and  the  data  set.  Section  3.6.4  takes  up 
this  point. 

A  friendly  organization  also  displays  threat  notification  and  threat  response  infonnation. 
Threat  notification  information  appears  immediately  upon  detection  of  a  threat.  It  is  pre¬ 
sented  in  a  pop-up  window  (Figure  7).  The  threat  list  on  the  right  side  of  the  map  window  is 
initially  redundant  with  respect  to  this  pop-up,  but  the  threat  lists  persists  for  as  long  as  the 
threat  exists. 

Threat  response  information  gives  decision  makers  a  set  of  possible  responses  to  a  threat. 
The  decision  support  application  generates  it  automatically  upon  detection  of  a  threat  and 
presents  it  as  soon  as  it  is  ready;  this  follows  shortly  after  the  threat  notification.  As  Figure  7 
shows,  it  contains  a  list  of  possible  courses  of  action  in  response  to  a  threat.  The  intent  is  that 
these  courses  of  action  be  generated  by  rules  derived  from  doctrine,  and  thus  useful  to  deci¬ 
sion  makers  as  justifiable.  Each  course  of  action  has  a  rating,  which  is  a  number  between  0 
and  1,  inclusive.  A  rating  of  1  means  the  course  of  action  is  always  justifiable  according  to 
doctrine.  A  rating  of  0  means  the  course  of  action  is  never  justifiable.  A  rating  in  between 
indicates  the  degree  of  justifiability.  By  default,  courses  of  action  with  a  rating  of  0  are  not 
shown. 
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Panzer bataillon  433:  Courses  of  Action 


Panzerbataillon  433:  Threat  Response  Coui'ses  of  Action 
"3C  Armor  Recce  Coy"  is  threatening  "Pameihataillon  433" 
Courses  of  Action  (2  of  4) 


2SJ 


Rating 

Course  of  Action 

0.834 

We  formulate  a  DEFEND  action  in  response  to  the  thr... 

View 

0.166 

We  request  permission  to  withdraw  from  our  location  i... 

View 

□  Show  Impossible  Courses  of  Action 


Select 


Cancel 


Figure  7.  Threat  Response:  Courses  of  Action 

If  a  user  clicks  the  View  button  to  the  right  of  a  course  of  action,  the  decision  support  applica¬ 
tion  pops  up  a  window  containing  the  rationale  for  the  rating  (Figure  8).  Figure  8  is  notional; 
it  should  provide  enough  information  for  a  decision  maker  to  understand  how  the  decision 
support  application  calculated  the  threat’s  rating.  The  decision  maker  may  agree  or  disagree 
with  the  logic  but  must  be  able  to  understand  it. 


Course  of  Action  Rationale 


We  formulate  a  DEFEND  action  in  response  to  the  threat. 
Rationale 

We  are  threatened. 

We  are  not  otherwise  tasked. 

Our  suppliesjare  adequate  for  defense  against  the  threat. 


OK 


Figure  8.  Example  Rationale 

A  friendly  organization  does  not  have  to  be  associated  with  a  set  of  decision  makers.  If  it  is 
not,  it  has  no  user  interface,  and  operates  autonomously. 

A  friendly  organization  that  is  associated  with  a  Generic  Hub  data  set  periodically  updates  its 
knowledge  base  from  that  data  set.  It  searches  the  REPORTING-DATA  table  for  rows  added  more 
recently  than  its  last  update.  If  it  finds  any,  it  creates  instances  of  ReportingData  in  its  knowl¬ 
edge  base.  It  also  detennines  what  observation  the  reporting  data  refers  to  and  creates  in¬ 
stances  in  the  knowledge  base  to  model  them. 

A  friendly  organization  also  updates  its  Generic  Hub  data  set.  Whenever  a  friendly  organiza¬ 
tion  generates  or  infers  information  that  can  be  expressed  in  terms  of  the  Generic  Hub  data 
model,  it  converts  the  frames  modeling  that  information  into  Generic  Hub  format,  then  in¬ 
vokes  its  associated  RDBMS  to  save  the  data. 


On  start-up,  a  friendly  organization  has  the  following  parameters: 

1 .  The  URL  of  a  GH  ontology. 

2.  The  URL  of  a  Generic  Hub  data  set.  This  parameter  is  optional;  if  not  given,  a  canned 
set  of  data  is  used  instead. 

3.  The  name  of  the  organization.  This  name  must  exist  in  the  Generic  Hub  data  set. 
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4.  The  interval,  in  seconds,  between  updates  of  the  knowledge  base  from  the  underlying 
Generic  Hub  data  set.  This  parameter  is  optional.  If  not  given,  the  interval  defaults  to 
60  seconds. 

5.  The  interval,  in  seconds,  between  analyses  of  the  knowledge  base  for  threats.  This  pa¬ 
rameter  is  optional.  If  not  given,  the  interval  defaults  to  50  seconds. 

6.  The  interval,  in  seconds,  between  searches  for  system  components  that  formulate 
courses  of  action  in  response  to  detected  threats.  This  parameter  is  explained  in  Sec¬ 
tion  3.2.2.  It  is  optional.  If  not  given,  the  interval  defaults  to  50  seconds. 

7.  The  interval,  in  seconds,  between  searches  for  system  components  that  synchronize 
changes  to  Generic  Hub  data  sets.  This  parameter  is  explained  in  Section  3.2.2.  It  is 
optional.  If  not  given,  the  interval  defaults  to  50  seconds. 

8.  The  URL  of  a  map  specification  document  (see  below). 

9.  A  name  that  is  unique  with  respect  to  names  of  all  other  system  components  that  will 
execute  on  the  computer  running  the  friendly  organization. 

A  friendly  organization  requires  a  map  specification  document  that  describes  the  location  and 
content  of  a  graphic  representing  a  map  image  to  display  in  a  decision  support  application.  A 
map  specification  document  is  an  XML  document.  A  map  specification  document  must  con¬ 
form  to  the  XML  Document  Type  Definition  (DTD)  shown  in  Figure  9. 

<!ELEMENT  map-spec  (map-URL,  center-point,  north-west-point)> 

<!ELEMENT  map-URL  (#PCDATA)> 

<!ELEMENT  center-point  EMPTY> 

<!  ATTLIST  center-point 

latitude  CDATA  #REQUIRED 
longitude  CDATA  #REQUIRED> 

<!ELEMENT  north-west-point  EMPTY> 

<!ATTLIST  north-west-point 

latitude  CDATA  #REQUIRED 
longitude  CDATA  #REQUIRED> 

Figure  9.  DTD  for  Map  Specification 

The  map-URL  element  specifies  the  URL  of  the  graphic  image  to  use  for  the  map.  The  image 
must  be  rectangular;  the  center-point  and  north-west-point  elements  specify  its  properties.  At¬ 
tributes  of  these  elements  must  be  given  in  decimal  degrees.  Figure  10  gives  an  example. 

<?xml  version- '1.0"  encoding="UTF-8"?> 

<DOCTYPE  map-spec  SYSTEM  ‘file:///C:/map-spec.dtd’> 

<map-spec> 

<map-URL>file://images/KilleenNW.png</map-URL> 

<center-point  longitude="-97.7426"  latitude- '31. 1419"/> 

<north-west-point  longitude="-97.8490"  latitude- '31.2104"/> 

</map-spec> 

Figure  10.  Example  Map  Specification  XML  Document 

2.3.  SimState 

A  Generic  Hub  data  set  mainly  represents  observations,  especially  with  respect  to  instance  of 
battlefield  objects.  It  may  specify  an  organization’s  position,  but  that  and  the  organization’s 
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actual  position  may  differ.  In  any  case,  it  qualifies  observations,  noting  that  position  is  as  of 
some  specified  time,  and  given  by  an  organization  of  specified  credibility. 

Friendly  organizations  have  intelligence  sources  that  provide  observations  of  the  battle  space. 
It  is  the  responsibility  of  a  friendly  organization  to  update  a  Generic  Hub  data  set  based  on 
intelligence  source  observations. 

The  prototype  simulation,  then,  must  simulate  intelligence  sources  surveying  the  battle  space 
for  battlefield  objects  during  each  execution.  This  could  be  accomplished  by  querying  the 
objects  directly,  but  having  a  friendly  organization  query  an  enemy  organization  is  illogical. 
Instead,  the  prototype  has  a  SimState  (Simulation  State)  component.  When  a  battlefield  ob¬ 
ject  changes  (or  initializes)  a  component  of  its  physical  state  that  can  be  described  in  terms  of 
the  Generic  Hub,  it  is  responsible  for  communicating  that  change  to  the  SimState  component. 
Intelligence  sources  may  query  the  SimState  component;  as  part  of  the  query  they  provide 
certain  parameters  (e.g.,  for  an  electronic  sensor,  center  point  and  radius  of  the  area  to  sur¬ 
vey)  and  the  SimState  component  responds  with  the  set  of  battlefield  objects  the  source  could 
detect  using  those  parameters,  based  on  the  most  recently  provided  state  information. 

Currently  the  SimState  component  only  recognizes  organizations  as  battlefield  objects,  i.e.,  it 
will  not  record  changes  to  the  state  of  any  battlefield  object  other  than  an  organization.  Its 
model  of  intelligence  sources  is  limited  to  providing  information  on  organizations  within  a 
rectangular  area  specified  by  two  points:  a  center  and  a  northwest.  This  primitive  implemen¬ 
tation  could  easily  be  extended  with  different  sensor  types. 

On  start-up,  the  SimState  component  may  be  provided  with  a  name  that  is  unique  with  re¬ 
spect  to  all  other  components  executing  on  the  computer  running  the  SimState  component. 
This  name  is  optional.  If  omitted,  it  defaults  to  ssa. 

2.4.  The  DBMS 

The  Generic  Hub  data  model  provides  a  physical  schema  for  implementation  as  a  relational 
database.  Any  realistic  application  must  expect  to  access  a  Generic  Hub  data  set  through  an 
RDBMS.  The  Generic  Hub’s  structure  is  too  complex  for  a  flat  file  implementation.  Non¬ 
trivial  data  sets  require  indexing  operations  for  acceptable  access  times.  Simultaneous  access 
by  multiple  applications  will  require  some  concurrency  mechanism.  These  features  are  all 
characteristic  of  functionality  offered  by  an  RDBMS. 

The  prototype,  therefore,  uses  an  RDBMS  to  store  GH-conformant  data  sets.  Aside  from  the 
above  features,  an  RDBMS  offers  the  following: 

•  Network  access.  The  location  of  the  Generic  Hub  data  and  the  computer  on  which  the 
DBMS  runs  need  not  be  tied  to  the  computer  running  any  other  system  component. 

•  Back-up  and  restore.  Snapshots  of  database  state  can  be  captured  and  reloaded;  this 
helps  establish  separate  simulation  configurations. 

•  Transaction  management.  This  simplifies  error  recovery. 

•  Data  replication.  Some  RDBMSs  can  automatically  replicate  data  across  multiple 
data  sets.  This  eliminates  the  need  for  friendly  organizations  to  exchange  Generic 
Hub-formatted  messages. 

Start-up  parameters  for  the  RDBMS  depend  on  its  implementation.  Vendor-supplied  docu¬ 
mentation  should  be  consulted  to  determine  them.  The  prototype  requires  that  the  RDBMS  be 
accessible  via  a  network  protocol  such  as  JDBC. 
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2.5.  Overview 

The  Overview  component  complements  the  SimState  component  by  giving  a  picture  of 
ground  truth.  It  shows  the  location  of  all  organizations.  See  Figure  11. 


Figure  11.  The  Overview  Component  GUI 

The  Overview  component  is  used  by  an  administrator  to  monitor  the  progress  of  a  simula¬ 
tion.  It  is  optional;  that  is,  a  simulation  can  take  place  without  an  Overview  component. 

On  start-up,  the  Overview  component  requires  as  a  parameter  a  name  that  is  unique  with  re¬ 
spect  to  names  of  all  other  system  components  that  will  execute  on  the  computer  running  the 
Overview  component. 

2.6.  Loader 

The  Loader  component  initiates  a  simulation.  It  parses  a  configuration  document  to  deter¬ 
mine  information  on  the  above  components:  which  ones  to  include  in  the  simulation.  It  then 
launches  the  components. 

Use  of  the  loader  is  optional.  However,  it  greatly  simplifies  the  initialization  process  and 
promotes  repeatability.  Furthermore,  its  user  interface  (shown  in  Figure  12)  allows  some 
visibility  into  and  control  over  a  simulation.  A  controller  can  start  all  enemy  organizations 
moving  (assuming  their  speed,  bearing  angles,  and  position  refresh  rates  have  been  set),  stop 
them,  and  shut  down  a  simulation  with  a  single  button  click. 

The  configuration  document  is  an  XML  document  conforming  to  the  DTD  shown  in  Figure 
13.  The  document  must  be  of  type  loader-config.  This  element  consists  of: 

•  A  set  of  elements  specifying  the  friendly  and  enemy  organizations  to  participate  in 
the  simulation. 


Enemy;  2 

Friendly;  0  (none  visible 
Overview:  0 

Start  Enemy  Orgs 

Stop  Enemy  Orgs 

Shut  Down  Loader 

Figure  12.  Loader  GUI 
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<!ELEMENT  c4i-config  ((friendly-org-spec  |  enemy-org-spec)*,  DB-spec?)> 
<!ATTLIST  c4i-config 

DB  (false|true)  "false" 
overview-agent  (off|on)  "off" 
ontology-URL  CDATA  #IMPLIED> 

<!ELEMENT  enemy-org-spec  (org-name)> 

<!ATTLIST  enemy-org-spec 

speed  CDATA  IMPLIED 
bearing-angle  CDATA  #IMPLIED 
visible  (false|true)  "true" 
position-refresh-rate  CDATA  #IMPUED> 

<!ELEMENT  friendly-org-spec  (org-name,  map-spec)> 

<!ATTLIST  friendly-org-spec 

threat-response-agent-search-interval  CDATA  "45" 
threat-search-interval  CDATA  "60" 
visible  (false|true)  "true" 

DBUpdate-agent-search-interval  CDATA  "100" 
ontology-refresh-interval  CDATA  "75"> 

<!ELEMENT  org-name  (#PCDATA)> 

<!ELEMENT  map-spec  (#PCDATA)> 

<!ELEMENT  DB-spec  (URL,  (user-name,  password?)?,  schema-map,  driver?)> 
<!ELEMENT  URL  (#PCDATA)> 

<!ELEMENT  user-name  (#PCDATA)> 

<!ELEMENT  password  (#PCDATA)> 

<!ELEMENT  schema-map  (#PCDATA)> 

<!ELEMENT  driver  (#PCDATA)> 

Figure  13.  DTD  for  Loader  Configuration 


•  An  optional  element  specifying  the  DBMS  that  components  will  use. 

•  Attributes  that  specify: 

•  Whether  to  use  a  RDBMS.  If  true,  the  RDBMS  element  must  be  given.  If 
false,  a  canned  data  set  will  be  used,  and  RDBMS-related  functionality  will  be 
lost. 

•  Whether  to  display  an  Overview  component. 

•  The  URL  of  a  GH  ontology.  (This  attribute  is  optional  in  the  XML  document, 
but  if  missing,  it  must  be  given  as  a  property  to  the  Java  runtime  environment. 
See  Section  3.6.8.) 

The  element  content  covers  the  start-up  parameters  for  each  component. 

The  loader  allows  only  one  RDBMS  to  be  specified.  All  components  the  loader  initiates 
share  this  RDBMS.  A  simulation  can  access  multiple  RDBMSs  by  invoking  the  loader  re¬ 
peatedly,  each  time  with  a  different  configuration  document.  Individual  components  may 
also  be  invoked  independently  of  the  loader,  and  their  start-up  parameters  may  include  dif¬ 
ferent  RDBMS  URLs. 

The  RDBMS  element  contains  URL  and  schema  map  elements,  both  of  which  are  required.  It 
may  also  include  a  user  name  and  password.  Some  DBMSs  require  a  user  name  and  pass- 
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word;  moreover,  the  user  name  and  password  sometimes  detennine  the  user’s  table  space, 
and  therefore  specify  the  particular  Generic  Hub  data  set  accessed.  Such  an  RDBMS  would 
pennit  access  to  multiple  Generic  Hub  data  sets  by  creating  different  user  accounts  and  asso¬ 
ciating  each  account  with  a  unique  table  space. 

The  RDBMS  element  also  contains  an  optional  driver  element.  This  element  specifies  a  Java 
class  implementing  a  JDBC  driver  manager. 

The  design  of  the  loader  does  not  attempt  to  consider  all  variabilities  of  RDBMS  access. 
Other  elements  may  be  necessary  to  access  other  RDBMSs. 

3.  Technical  View 

This  section  presents  design  and  implementation  decisions  for  each  component  in  the  System 
View.  It  discusses  the  technologies  used  to  implement  the  simulation  prototype,  showing 
how  they  contribute  to  an  agile,  easily  extendable  design.  It  covers  the  simulation  prototype 
components  in  terms  of  their  task  structure  and  their  packaging  (i.e.,  breakdown  into  mod¬ 
ules).  It  gives  a  detailed  discussion  of  selected  components  that  are  especially  interesting  in 
the  implementation  of  a  net-centric  system. 

In  compliance  with  principles  of  net-centricity,  the  system  is  implemented  as  a  set  of  inter¬ 
acting  agents.  These  agents  base  their  analyses  on  ontologies  and  knowledge  bases  insofar  as 
is  practical.  This  is  as  opposed  to  implementing  business  rules  in  a  programming  language. 

3.1.  Underlying  and  Supporting  Technologies 

Many  technical  decisions  on  the  design  of  the  prototype  simulation  stem  from  the  technolo¬ 
gies  used  in  its  development: 

•  The  prototype  simulation  is  implemented  in  Java  [Java].  All  source  code  is  written  in 
Java,  is  written  in  a  language  for  which  a  Java  parser  generator  exists,  or  is  written  in 
a  language  that  is  interpreted  by  components  written  in  Java. 

•  The  primary  system  for  manipulating  ontologies  and  knowledge  bases  is  Protege- 
2000  [Protege  2004],  Extensions  to  knowledge  base  functionality  derive  from  plug¬ 
ins  available  for  Protege-2000.  (Some  design  decisions  are  based  on  hypothesized 
plug-ins.) 

•  The  system  for  implementing  agent-based  capabilities  is  FIPA-OS  [FIPA-OS].  Be¬ 
cause  FIPA-OS  has  support  for  interprocess  communication,  it  is  also  used  to  imple¬ 
ment  functionality  for  certain  components  that  are  not  true  agents  but  are  most  easily 
or  realistically  implemented  as  distinct  processes. 

•  The  system  for  translating  between  XMF  documents  and  Java  objects  is  Zeus  [Enhy- 
dra].  Zeus  uses  Document  Type  Definitions  (DTDs)  rather  than  the  newer  XMF 
Schema  Definitions  (XSDs).  DTDs  are  not  as  powerful  as  XSDs,  but  they  are  much 
easier  to  create  and  use,  and  they  are  sufficiently  expressive  for  this  prototype  simula¬ 
tion. 

The  following  discussion  of  these  technologies  will  aid  in  understanding  the  subsequent  de¬ 
tailed  discussion  of  system  design. 

3.1.1.  Java 

Many  features  of  Java  make  it  an  excellent  language  in  which  to  implement  this  prototype 
simulation.  Java  is  by  design  platform-independent,  freeing  implementers  from  platfonn- 
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specific  considerations.  Its  standard  libraries  provide  useful  capabilities  for  letting  an  applica¬ 
tion  interface  with  its  environment.  Many  freely  available  packages  provide  cutting-edge 
functionality;  perhaps  more  significant,  many  freely  available  packages  (including  the  stan¬ 
dard  libraries)  provide  key  basic  functionality  such  as  sorting  and  searching. 

Java’s  ability  to  load  classes  at  run-time  adds  considerable  flexibility.  Dynamically  declared 
classes  can  be  used  to  decouple  components  of  a  program;  Java’s  SQL  package  uses  dynamic 
classes  to  manage  the  JDBC  driver  used  to  connect,  for  example,  a  program  to  an  RDBMS. 
Dynamic  classes  are  also  a  useful  implementation  technique  for  converting  data  exchanged 
between  applications  (such  as  agent  messages)  into  Java  objects.  FIPA-OS  and  Zeus  use  dy¬ 
namic  classes  for  this  purpose.  So  does  the  prototype  simulation. 

Java’s  standard  libraries  formalize  the  concept  of  a  URL  and  make  access  to,  and  reading  of, 
a  URL  simple  and  straightforward.  This  greatly  simplifies  system  configuration  by  decoup¬ 
ling  an  application  from  its  data. 

3.1.2.  Protege-2000 

Protege-2000  is  often  invoked  with  a  user  interface  that  lets  it  serve  as  an  ontology  definition 
tool  and  a  knowledge  base  editor,  but  it  also  provides  an  API  that  an  application  may  use  to 
access  that  same  editing  functionality.  The  Protege-2000  data  model  is  based  on  OKBC.  The 
API  provides  Java  classes  and  interfaces  that  provide  direct  access  to  the  data  model.  These 
classes  and  interfaces  are  contained  in  the  package  edu.stanford.smi. protege. model. 

The  interfaces  specify  an  OKBC  view  of  data.  They  define  the  hierarchy  shown  in  Figure  14. 
The  API  of  the  top-level  interface,  Frame,  specifies  methods  needed  for  all  interfaces: 

•  Get/set  methods  to  manipulate  a  frame’s  name,  own  slot  values,  and  facet  values. 

•  Get  methods  to  obtain  a  frame’s  own  slots,  certain  properties  associated  with  own 
slots  (e.g.,  the  number  of  values  an  own  slot  possesses),  and  facets  of  own  slots. 

•  Add/remove  methods  to  affect  facets,  and  also  to  change  the  own  slot  value  for  a 
frame  of  multiple  cardinality. 

•  A  method  to  obtain  the  knowledge  base  in  which  the  frame  exists.  (Protege-2000  does 
not  permit  multiple  knowledge  bases  to  share  a  frame.) 

•  Boolean-valued  methods  to  test  properties  of  a  frame,  including  validity  (currently 
validity  means  only  that  Protege-2000  allocated  the  frame  correctly)  and  editability. 
Corresponding  set  methods  are  defined  to  set  these  properties. 

Applications  usually  deal  with  subinterfaces  of  Frame  rather  than  directly  with  Frame  itself. " 
Instance,  the  direct  descendent  of  Frame,  adds  get/set  methods  that  make  a  frame  an  instance 
of  a  class.  Most  applications  want  frames  that  are  instances  of  classes,  so  Instance  is  more 
useful  than  Frame.  (A  comment  in  the  API  documentation  for  Instance  indicates  that  Protege- 


Figure  14.  Protege-2000  Components  of  OKBC  Model 
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2000’s  designers  considered,  but  decided  against,  merging  the  Frame  and  Instance  inter¬ 
faces.3) 

The  CIs  interface  (so  named  because  Java  defines  Class  as  a  class  in  its  language  standard) 
extends  Instance  with: 

•  Get/set  methods  to  manipulate  template  slots,  direct  subclasses,  and  direct  super¬ 
classes.  Certain  properties  of  template  slots,  such  as  cardinality,  can  also  be  manipu¬ 
lated. 

•  Add/remove  methods  to  affect  the  template  slots,  template  slot  values,  and  template 
facet  values  of  a  class. 

•  Get  methods  that  obtain  class  properties,  including  the  number  of  direct  and  total  in¬ 
stances,  the  superclasses,  and  the  subclasses. 

•  A  method  to  create  a  direct  instance  (i.e.,  an  object  of  type  Instance)  of  a  class.  The 
own  slots  of  the  instance  are  undefined  unless  the  corresponding  template  slots  have  a 
default  value. 

•  Boolean  methods  to  test  class  properties  such  as: 

•  Whether  the  class  is  abstract  or  concrete. 

•  Whether  the  class  possesses  a  specified  template  slot. 

•  Whether  the  class  overrides  the  definition  of  a  template  slot  or  facet  inherited 
from  a  superclass. 

The  Slot  interface  specifies  methods  that  get  or  set  properties  of  a  slot  (but  not  its  value;  a 
Frame  specifies  value  properties  of  an  own  slot,  and  a  CIs  specifies  value  properties  of  a  tem¬ 
plate  slot).  These  properties  include  cardinality,  value  type,  allowed  classes  (if  the  value  type 
is  “Instance”)  allowed  parents  (if  the  value  type  is  “Class”),  and  inverse.  In  the  Protege-2000 
model,  a  slot  is  represented  as  an  instance  of  class  :SLOT.  Therefore  the  Slot  interface  extends 
Instance. 

The  Facet  interface  extends  Instance  with  get/set  methods  for  placing  constraints  on  slots.  In 
Protege-2000,  facets  add  little  power,  because  their  capabilities  are  all  implemented  as  part  of 
knowledge  base  functionality.  The  prototype  simulation  does  not  use  the  Facet  interface. 

Frames  are  part  of  a  knowledge  base.  The  KnowledgeBase  interface  specifies  methods  for  ma¬ 
nipulating  frames.  These  include: 

•  Get  methods  to  obtain  all  extent  frames,  instances,  classes,  slots,  and  facets. 

•  Get  methods  that  obtain  properties  (e.g.,  count  of  all  instances). 

•  A  set  method  that  specifies  whether  Protege-2000  should  validate  the  value  of  an  own 
slot  with  respect  to  its  facets  whenever  its  value  changes. 

Protege-2000  supplies  implementations  for  all  these  interfaces.  An  application  accesses  them 
by  creating  an  instance  of  the  Project  class,  usually  via  the  static  method 
Project.loadProjectFromFileQ.  The  parameters  to  this  method  include  the  name  of  a  file  (it  may 
also  be  a  URL)  containing  a  Protege-2000  “project”.  A  project  specifies  an  ontology,  a 
knowledge  base  (which  may  be  empty),  and  certain  details  useful  to  Protege-2000’s  knowl¬ 
edge  base  editor;  it  is  the  means  by  which  both  users  and  applications  access  a  knowledge 
base.  Applications  using  Protege-2000 ’s  API  usually  contain  code  similar  to  the  following: 


3  http://protege.stanford.edu/doc/pdk/api/index.html;  under  package  edu. Stanford. smi. protege. model,  select  in¬ 
terface  Instance. 
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Collection  errors  =  new  LinkedList(); 

Project  project  =  Project.loadProjectFromFile(“project.pprj”,  errors); 
if  ( errors.size()  >  0 ) 

throw  new  Exception(“Cannot  load  project”); 

KnowledgeBase  kb  =  project.getKnowledgeBase(); 

The  upshot  of  this  code  is  that  Protege-2000  has  supplied  an  instance  of  a  knowledge  base 
that  can  subsequently  serve  to  access  all  other  interfaces  of  the  model.  For  example,  an  appli¬ 
cation  can  create  an  instance  of  a  Unit  and  set  its  slots  as  follows: 

CIs  unitCIs  =  kb.getCls(“Unit”); 

Instance  unit  =  unitCls.createDirectlnstance(null);  II  null  makes  Protege-2000  generate  a 

II  unique  frame  name  automatically. 

Slot  tiv  =  kb.getSlot(“type-instance-value”);  II  Well  use  this  each  time  we  set  a  slot’s  value. 

II  Set  the  unit’s  name  to  “1  (DA)  AA  Company”. 

Instance  unitName  =  kb.getCls(“Object-ltem-Name”).createDirectlnstance(); 
unitName.setOwnSlotValue(tiv,  “1  (DA)  AA  Company”); 
unit.setOwnSlotValue(kb.getSlot(“name”),  unitName); 

II  Set  the  unit’s  formal  abbreviated  name  to  “1C(AA)-1BD”. 

Instance  formalAbbreviatedname  =  kb.getCls(“Unit-Formal-Abbrev-Name”).createDirectlnstance(); 
formalAbbreviatedName.setOwnSlotValue(tiv,  “1C(AA)-1BD"); 
unit.setOwnSlotValue(kb.getSlot(“formalAbbreviatedName”),  formalAbbreviatedName); 

II  Set  the  unit’s  category  code  to  “UN”.  Note  that  we  don’t  create  a  value; 

II  we  use  values  in  the  DS149_org_cat_code  enumerated  type. 

Slot  eelSIot  =  kb.getSlot(“enumerated-element-label”); 

Collection  orgCatCodes  =  kb.getCls(“DS149_org_cat_code”).getlnstances(); 

Instance  unlnst; 

for  ( Iterator  cclter  =  orgCatCodes. iteratorO;  cclter.hasNext(); )  { 
unlnst  =  (lnstance)cclter.next(); 

Instance  element  =  (Instance)unlnst.getOwnSlotValue(tiv); 
if  ( element.getOwnSlotValue(eelSlot).equals(“UN”) ) 
break; 

} 

unit.setOwnSlotValue(kb.getSlot(“categoryCode”),  unlnst); 

Later,  an  application  can  associate  a  location  with  this  unit: 

Instance  location  =  ...;  //We  assume  these  instances  are 
Instance  speed  =  . . . ;  II  obtained  from  somewhere. 

Instance  objltemLoc  =  kb.getCls(“ObjectltemLocation”).createDirectlnstance(); 
unit.addOwnSlotValue(kb.getSlot(“is-geometrically-defined-through-ObjectltemLocation”), 
objltemLoc); 

location.addOwnSlotValue(kb.getSlot(“provides-geometric-definition-for-ObjectltemLocation”), 

objltemLoc); 

objltemLoc.setOwnSlotValue(kb.getSlot(“speedRate”),  speed); 

It’s  worth  noting  again  that  Protege-2000  only  verifies  a  set  operation  if  the  method 
kb.setValueChecking()  has  been  invoked  with  a  true  value  for  its  parameter.  These  checks  can 
be  time-consuming,  so  by  default  Protege-2000  places  the  onus  of  verification  on  the  applica¬ 
tion. 


B-18 


3.1.3.  FIPA  and  FIPA-OS 

The  Foundation  for  Intelligent  Physical  Agents  (FIPA)  [FIPA]  is  a  standards  organization 
that  has  written  and  published  numerous  standards  for  the  design  and  implementation  of 
agent-based  systems.  The  core  of  FIPA  is  an  abstract  architecture  that  defines  elements  of  an 
environment  of  communicating  agents.  This  architecture  has,  at  its  most  abstract,  four  ele¬ 
ments: 

1.  The  message  transport  element,  which  defines  how  messages  exchanged  by  agents 
will  be  communicated  across  a  network. 

2.  The  agent  communication  language  (ACL)  element,  which  standardizes  the  structure 
of  messages  in  terms  of  a  set  of  parameters  with  predefined  meanings. 

3.  The  agent  directory  element,  which  specifies  how  agents  are  to  announce  their  pres¬ 
ence  and  how  other  agents  may  detect  them. 

4.  The  service  directory  element,  which  specifies  how  agents  can  characterizes  the  ser¬ 
vices  they  offer,  and  how  other  agents  may  search  for  services. 

FIPA  states  that  one  (optional)  parameter  of  an  ACL  is  the  ontology.  In  other  words,  an 
agent’s  message  may  include  a  reference  to  an  ontology  that  defines  the  content  of  the  mes¬ 
sage  and,  depending  on  the  sophistication  of  the  ontology,  lets  other  agents  interpret  message 
content.  The  degree  to  which  message  interpretation  is  possible  varies  from  recognizing  the 
name  of  an  ontology  (and  assuming  that  name  refers  to  the  same  ontology  one  has  in  mind) 
to  ontology  translation  services  based  on  first-order  predicate  calculus. 

FIPA-OS  is  an  implementation  of  many  of  the  FIPA  standards.  In  particular,  it  fully  imple¬ 
ments  the  abstract  architecture,  and  thereby  provides  a  foundation  upon  which  all  other  FIPA 
standards  can,  or  have  been,  implemented. 

3. 1.3.1.  Agents 

Figure  15  shows  the  life  cycle  of  a  FIPA-OS  agent.  An  agent  is  an  instance  of  a  subclass  of 
class  FIPAOSAgent  (in  Figure  15,  assume  class  MyAgent  is  such  a  class).  For  an  agent  to  oper¬ 
ate,  an  Agent  Management  System  (AMS)  and  a  Directory  Facilitator  (DF)  must  be  running 
in  the  environment  hosting  the  agent  (usually  the  host  computer).  Agent  o’ s  first  order  of 
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business  is  to  register  itself  with  the  AMS,  supplying  its  name  and  address.  The  AMS,  which 
is  FIPA-OS’s  name  for  the  agent  directory  element,  notes  these  items;  a  has  effectively  de¬ 
clared  itself  as  part  of  the  environment,  and  can  now  be  contacted  by  other  agents.  The  ad¬ 
dress  a  gives  suffices  to  let  other  agents  in  the  environment  identify  it  uniquely,  and  to  con¬ 
tact  it.  Depending  on  how  the  AMS  is  configured,  this  environment  may  be  as  narrow  as  the 
host  computer  or  as  wide  as  the  entire  Internet. 

The  agent  next  registers  its  services  with  the  DF,  which  is  FIPA-OS’s  name  for  the  service 
directory  element.  The  purpose  of  the  DF  is  to  help  agents  search  for  services  they  require. 
FIPA-OS  lets  a  service  be  specified  in  several  ways.  The  agent  may  simply  give  its  name, 
implying  that  its  services  are  standard  enough  that  other  agents  can  be  expected  to  know 
about  them.  The  agent  may  also  state  the  names  of  ontologies  it  understands,  names  of  lan¬ 
guages  it  supports  (natural,  artificial,  or  both),  and  names  of  communication  protocols  it  uses. 
Finally,  an  agent  may  provide  one  or  more  service  descriptions.  A  service  description  has  a 
name  and  a  set  of  agent-specific  properties,  each  of  which  is  a  name/value  pair.  The  implica¬ 
tion  of  a  property  is  that  its  name  is  something  for  which  an  agent  might  search,  and  its  value 
will  inform  an  agent  of  whether  the  service  is  useful. 

An  agent  may  use  any  combination  of  these  search  terms.  Providing  a  name  and  a  service 
description  is  perfectly  legal.  In  fact,  a  service  description  may  also  specify  ontologies,  lan¬ 
guages,  and  protocols.  This  might  be  particularly  useful  in  multilingual  environments;  an 
agent  could  announce  that  it  provides  services  for  the  Generic  Hub,  the  Moyeu  Generique, 
and  the  Generische  Nabe,  specifying  each  as  a  separate  service  description  with  property 
names  and  values  of  the  GH  ontology  in  respective  languages. 

In  all  cases,  agents  conduct  searches  by  name.  The  assumption  is  that  names  are  sufficiently 
powerful  and  unambiguous  to  identify  desired  services.  The  validity  of  this  assumption  re¬ 
mains  to  be  seen. 

After  an  agent  has  registered  with  the  AMS  and  the  DF,  it  begins  performing  its  assigned 
tasks;  when  it  has  finished,  it  deregisters,  then  shuts  down  by  invoking  the  shutdown()  method 
in  the  FIPAOSAgent  superclass.  This  completes  its  life  cycle. 

3. 1.3.2.  Tasks 

Agents,  by  their  nature,  engage  in  synchronous  and  asynchronous  communication  with  each 
other.  An  agent  is  inherently  a  multi-tasking  entity.  Java’s  Thread  class  provides  support  for 
multiple  tasks,  but  a  thread  is  more  general  than  necessary  for  agent  implementation.  FIPA- 
OS  provides  an  abstract  Task  class  that  is  tailored  to  agent  needs.  It  provides  methods  for: 

•  Searching  for  agents. 

•  Initiating,  performing,  and  terminating  conversations  with  agents. 

•  Creating  a  hierarchy  of  tasks. 

•  Gracefully  terminating  a  task. 

Similar  to  agents,  an  application  extends  the  class  Task  to  create  a  concrete  class  implement¬ 
ing  specific  functionality.  Because  tasks  are  created  in  a  hierarchy,  the  agent  invokes  the  root 
task,  then  waits  for  it  to  tenninate.  The  paradigm  for  implementing  an  agent  is  therefore: 
public  class  MyAgent  extends  FIPAOSAgent  { 
public  MyAgent(String  agentName)  { 

super(prof/7e,  agentName,  “FIPA-OS”,  true); 

registerWithAMSQ;  II  Automatically  supplies  the  agent’s  name. 
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registerWithDF(agentName);  II  Can  also  give  a  service  description. 
setListenerTask(  new  MyTask() );  II  Now  MyAgent  will  wait  until  MyTask  terminates. 

} 

/**  Callback  method  invoked  automatically  by  FIPA-OS  when  MyTask  terminates.  */ 
public  void  doneMyTask(Task  t)  { 

deregisterWithDF();  II  De-register  in  the  opposite  order  of  registration! 

deregisterWithAMS(); 

shutdown(); 

} 

} 

Aside  from  MyTask(),  all  the  methods  invoked  are  defined  in  FIPAOSAgent. 

The  task  hierarchy  an  agent  uses  depends  entirely  on  the  functionality  the  agent  provides.  A 
typical  agent  has  both  periodic  and  aperiodic  functionality.  It  may  be  proactive,  reactive,  or 
both.  Each  functional  category  will  occupy  its  own  place  in  the  hierarchy. 

As  an  example,  consider  enemy  organizations.  Each  enemy  organization  is  implemented  as 
an  agent.  An  enemy  organization  periodically: 

1 .  Updates  its  position. 

2.  Sends  its  position  to  the  SimState  component. 

3.  Sends  its  position  to  any  Overview  components. 

The  SimState  and  Overview  components  are  implemented  as  agents  that  register  themselves 
and  their  services.  The  second  and  third  of  these  actions  require  locating  these  agents.  It  is 
assumed  that  one  SimState  component  always  exists  -  the  system  cannot  run  otherwise  -  but 
Overview  components  may  come  and  go  during  execution.  An  enemy  organization  must  pe¬ 
riodically  search  for  Overview  components. 

Based  on  these  considerations,  the  agent  that  implements  an  enemy  organization  uses  the  task 
structure  shown  in  Figure  16.  The  root  task  is  named  IdleT ask;  this  is  a  FIPA-OS  convention. 
Its  role  is  to  start  the  other  tasks,  await  their  completion,  then  terminate,  at  which  time  FIPA- 
OS  will  attempt  to  invoke  the  doneldleTask()  method  of  the  agent  that  started  it.  If  this  method 
exists  and  is  public,  it  will  likely  contain  code  similar  to  the  canonical  agent  presented  above, 
so  the  agent  will  tenninate.  (If  this  method  does  not  exist,  the  agent  must  have  another  strat¬ 
egy  to  terminate.) 

The  Idle  Task  starts  three  tasks.  Each  of  these  tasks  operates  independently: 

•  The  SimState  Agent  Search  Task  uses  FIPA-OS  to  search  the  DF  for  the  SimState 


Figure  16.  Enemy  Organization  Agent  Task  Hierarchy 
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Figure  17.  SimState  Agent  Search:  Task  Interactions 


agent.  Upon  finding  the  SimState  agent,  FIPA-OS  passes  the  SimState  Agent  Search 
Task  an  ID  that  unambiguously  identifies  the  SimState  agent,  and  that  can  be  used  in 
subsequent  communications.  The  SimState  Agent  Search  Task  in  turn  passes  this  ID 
to  the  Enemy  Organization  agent,  then  terminates.  See  Figure  17. 

•  The  Overview  Agents  Search  Task  invokes  a  Periodic  Agent  Search  Task;  as  its  name 
implies,  this  task  performs  a  search,  waits  for  a  specified  period  of  time,  then  repeats 
this  search/wait  cycle,  continuing  until  instructed  by  its  parent  task  to  terminate. 
FIPA-OS  provides  an  implementation  of  the  Wait  Task.  To  use  it,  one  instantiates  the 
WaitTask  class,  passing  the  desired  wait  time  in  milliseconds  as  a  parameter.  When 
this  time  has  elapsed,  FIPA-OS  invokes  the  method  doneWaitTaskQ  in  the  instance  that 
started  the  Wait  Task. 

Figure  18  below  shows  canonical  Java  code  for  implementing  a  periodic  task.  The 
Overview  Agent  Search  Task  conforms  to  this  paradigm,  substituting  an  invocation  of 
Agent  Search  Task  for  the  generic  performSomeAction(). 

•  The  Recalculate  Position  Task  differs  from  the  other  two  tasks  in  that  it  is  launched 
by  the  Idle  Task  not  automatically  but  by  external  command.  This  command  comes 
either  from  an  enemy  organization  controller  via  the  agent’s  user  interface  (when  the 
controller  checks  the  Organization  Moving  box;  see  Figure  3)  or  from  the  loader. 
Once  it  starts,  it  uses  the  paradigm  in  Figure  18,  perfonning  the  necessary  mathemat¬ 
ics  in  the  doneWaitTaskQ  method  to  compute  the  organization’s  new  location. 
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The  Recalculate  Position  Task  may  also  be  stopped  via  external  command.  The  en¬ 
emy  organization  agent  is  implemented  such  that  the  Idle  Task  receives  the  com¬ 
mand;  when  it  does,  it  tells  the  Recalculate  Position  Task  to  stop.  (In  FIPA-OS,  a  par¬ 
ent  task  cannot  kill  its  child;  it  only  receives  notification  of  changes  to  a  child’s  state.) 

3. 1.3.3.  Messages  and  Conversations 

Agents  send  messages  to  each  other.  Every  message  has  an  associated  communicative  act 
that  describes  the  intent  of  the  message.  FIPA  specifies  a  predefined  set  of  standard  commu¬ 
nicative  acts,  and  provides  a  formal  semantic  model  of  each.  Examples  of  communicative 
acts  include: 

•  Inform :  The  sender  informs  the  receiver  that  the  sender  believes  a  given  proposition  is 
true. 

•  Not  Understood'.  The  sender  informs  the  receiver  that  it  believes  the  receiver  has  per¬ 
formed  some  action,  but  it  does  not  understand  that  action.  The  most  common  use  for 
this  communicative  act  is  for  the  sender  to  notify  the  receiver  that  it  does  not  under¬ 
stand  the  contents  of  an  Inform  communicative  act  the  receiver  sent  to  the  sender  ear¬ 
lier. 

•  Request :  The  sender  requests  the  receiver  to  perform  some  action.  Usually  the  action 
requests  that  the  receiver  respond  to  the  sender  with  an  Inform  communicative  act. 

•  Failure :  The  sender  informs  the  receiver  that  it  attempted,  but  failed,  to  perform  some 
action. 

In  FIPA,  every  message  is  part  of  a  conversation.  A  conversation  prescribes  a  message  se¬ 
quence  according  to  an  ordering  of  communicative  acts.  This  ordering  is  known  as  the  proto¬ 
col.  FIPA-OS  supplies  several  protocols,  and  lets  applications  specify  their  own.  Examples  of 
FIPA-OS  protocols  include: 

•  No-Protocol:  The  simplest  protocol,  it  defines  a  one-message  conversation  that  al¬ 
lows  any  communicative  act.  In  other  words,  the  sender  sends  the  receiver  an  arbi¬ 
trary  message  and  expects  no  reply. 

•  FIPA-Request:  In  this  protocol,  agent  A  requests  some  action  of  agent  B  (typically 
that  B  supply  information),  and  agent  B  either  agrees  or  refuses  to  participate  in  the 


public  class  PeriodicTask  extends  Task  { 
private  int  delayTime  =  10000; 

/**  Callback  method  invoked  automatically  when  the  task  starts.  */ 
public  void  startTaskQ  { 

newTask(  new  WaitTask(delayTime) );  II  Delay  for  a  while. 

} 

*/ 

is  supposed  to  do. 


/**  Callback  method  invoked  automatically  when  a  WaitTask  terminates, 
public  void  doneWaitTask(Task  t)  { 

performSomeActionQ]  II  Do  what  PeriodicTask 

newTask(  new  WaitTask(delayTime) );  II  Now  repeat  the  cycle. 

} 


Figure  18.  Canonical  Code  for  Periodic  Task 
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conversation.  If  agent  B  agrees,  it  attempts  to  perfonn  the  action;  it  then  sends  to  A  a 
message  with  either  an  Inform  or  a  Failure  communicative  act. 

Protocols  can  specify  conversations  of  little  or  great  complexity.  A  conversation  can  contain 
cycles,  so  agents  can  communicate  as  much  as  they  need  for  as  long  as  they  need. 

In  FIPA-OS,  most  conversations  are  initiated  by  tasks.  (Agents  may  also  initiate  conversa¬ 
tions,  but  methods  in  the  Task  class  provide  better  support.)  A  task  constructs  a  conversation 
using  the  getNewConversation()  method,  which  takes  a  protocol  name  as  its  parameter  and  re¬ 
turns  an  ACL  message  whose  communicative  act  is  set  to  that  of  the  first  communicative  act 
for  the  protocol.  The  task  then  fills  in  the  content  of  the  ACL  message  and  invokes  the 
forward()  method,  which  sends  the  ACL  message  to  the  recipient: 

ACL  acl  =  getNewConversation(“fipa-request”);  II  The  parameter  is  the  protocol’s  name. 

acl.setReceiverAID(agenf  ID  of  receiver); 

acl.setContent(message  content ); 

acl.setOntology(message  ontology ); 

forward(acl); 

The  sender  is  assuming  the  receiver  knows  how  to  handle  a  conversation  that  uses  the  FIPA- 
Request  protocol. 

A  task  handles  conversations  by  declaring  methods  with  names  based  on  the  communicative 
acts.  For  the  above  example,  the  receiver  will  handle  the  conversation  if  it  declares  a  method 
as  follows: 

/**  Callback  method  invoked  on  receiving  a  message  with  a  Request  communicative  act.  */ 
public  void  handleRequest(Conversation  c)  { ... } 

From  the  Conversation  parameter,  the  method  can  extract  the  message  and  detennine  its  con¬ 
tent,  ontology,  sender,  etc. 

FIPA-OS  supports  conversations  with  a  more  complex  protocol  by  maintaining  within  an 
agent  the  state  of  the  conversation,  i.e.,  the  sequence  of  messages  already  sent  and  the  valid 
next  messages  (including  whether  the  conversation  is  over).  Thus  the  body  of  a  conversation¬ 
handling  method  looks  something  like  the  following: 

public  void  handleRequest(Conversation  c)  { 

ACL  acl  =  c.getACL(c.getLatestMessagelndex());  II  Get  the  message  to  handle, 
if  ( I  acl.getProtocol.equalslgnoreCase(“fipa-request”) )  { 
sendNotUnderstood(acl); 
return; 

} 

try  { 

II  Perform  task-specific  actions  that  generate  a  response. 

Object  result  =  interpret(acl.getOntology(),  acl.getContent()); 

ACL  response  =  getResponse(c,  “inform”); 
response. setContent(result.toString()); 
forward(response); 

}  catch  ( InterpretationException  e )  {  II  Application-defined  execption. 

II  Could  not  complete  the  action. 

ACL  response  =  getResponse(c,  “Failure”); 
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response. setContent(acl.getContent());  II  Let  sender  know  what  failed. 

forward(response); 

} 

} 

/**  Gets  from  a  conversation  the  next  message  with  the  specified  performative  (“performative”  is 
*  the  FIPA-OS  name  for  a  communictive  act).  */ 
private  ACL  getResponse(Conversation  c,  String  performative)  { 
for  ( Iterator  i  =  c.getNextMessages().iterator();  i.hasNext(); )  { 

ACL  acl  =  (ACL)i.next(); 

if  ( acl.getPerformative.equalslgnoreCase(performative) ) 
return  acl; 

} 

return  null; 

} 

Most  methods  in  a  task  are  devoted  to  handling  communicative  acts. 

A  message  has  exactly  one  sender  but  may  have  multiple  recipients.  FIPA-OS  creates  in  the 
sending  task  a  separate  conversation  thread  for  each  recipient.  Usually  the  sending  task  will 
want  to  create  a  child  task  to  handle  each  thread. 

3. 1.3. 4.  Ontologies,  Languages,  and  Message  Content 

The  heart  of  a  message  is  its  content.  Every  non-trivial  message  has  content  that  informs  the 
receiver  of  the  sender’s  intent:  a  query,  a  response,  unsolicited  information,  etc.  The  chal¬ 
lenge  of  an  agent-based  environment  is  to  ensure  that  the  sender  provides  enough  informa¬ 
tion  to  allow  the  receiver  to  unambiguously  interpret  content. 

FIPA  defines  three  message  parameters  that  specify  semantics.  The  first  is  the  communica¬ 
tive  act.  In  the  context  of  “Inform”,  the  content  “time  flies”  could  be  interpreted  to  mean  that 
things  happen  quickly,  whereas  in  the  context  of  “Request”  it  could  mean  that  the  recipient  is 
to  measure  the  speed  of  winged  insects,  or  perhaps  batted  baseballs. 

The  second  parameter  is  the  ontology  name.  The  elements  of  the  ontology  should  allow  the 
receiving  agent  to  identify  the  entities  and  actions  of  the  content  (e.g.,  insects  versus  base¬ 
balls). 

An  ontology  is  identified  by  name.  FIPA  does  not  require  the  receiver  to  implement  the  on¬ 
tology.  It  provides  for  the  existence  of  an  ontology  server  that  can  interpret  content  in  the 
context  of  an  ontology.  The  receiver  provides  the  ontology’s  name  to  this  server.  This  tech¬ 
nology  is  still  experimental,  however,  and  its  viability  is  unproven  for  large  knowledge  bases. 
The  agents  in  this  system  do  not  use  an  ontology  server,  instead  accessing  Protege-2000  di¬ 
rectly. 

The  third  parameter  states  the  language  of  the  content.  FIPA  does  not  constrain  what  this 
might  be.  Natural  languages  (English,  French,  German)  are  permitted,  though  their  use  usu¬ 
ally  indicates  a  message  for  which  precise  semantic  disambiguation  is  unnecessary.  Some 
agents  use  XML,  especially  for  messages  in  which  syntax  rather  than  semantic  interpretation 
is  needed.  Extensions  of  XML  such  as  the  Resource  Description  Framework  and  the  Web 
Ontology  Language  add  some  semantics. 

Some  agents  use  formal  languages,  such  as  Prolog.  FIPA  defines  two  preferred  languages  for 
agent  communication:  Choice  Constraint  Language  (CCL)  and  Semantic  Language  (SL). 
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CCL  is  the  preferred  language  for  constraint  satisfaction  problems  (CSPs).  A  CSP  is  a  prob¬ 
lem  where,  given  a  finite  set  of  variables  (each  of  a  finite  domain)  and  a  finite  set  of  con¬ 
straints  between  the  variables,  a  solution  is  an  assignment  of  values  to  each  variable  such  that 
no  constraints  are  violated.  It  is  useful  for  posing  questions  such  as  “Given  a  certain  dinner 
menu,  what  wine  would  be  appropriate?”  and  “Under  current  conditions,  what  routes  are  not 
available  to  a  convoy?” 

SL  is  based  on  first-order  predicate  calculus.  The  syntax  is  based  on  s-expressions  (parenthe¬ 
sized  terms  with  a  prefix  operator).  Content  may  be: 

•  A  proposition,  i.e.,  a  statement  of  the  truth  or  falsehood  of  a  fact.  A  proposition  is  ex¬ 
pressed  as  a  well-formed  formula.  A  proposition  is  used  as  the  content  of  an  Inform 
communicative  act. 

•  An  action  expression,  which  is  a  request  for  an  agent  to  perform  some  action;  the  con¬ 
tent  of  the  action  expression  describes  the  nature  of  the  action.  An  action  expression 
is  used  as  the  content  of  a  Request  communicative  act. 

•  An  identifying  reference  expression,  which  basically  establishes  one  collection  of  ob¬ 
jects  as  synonymous  with  another.  It  is  used  as  the  content  of  the  Infonn-Ref  commu¬ 
nicative  act,  a  special  type  of  Infonn  act.  Agent  A  asks  B  for  all  synonyms  of  S;  rather 
than  simply  replying  with  a  set  {si,  5 2,  . ..},  B  responds  with  a  sentence  that  states  “all 
synonyms  of  S  are  {si,  S2,  ...}”.  This  explicit  connection  is  often  necessary  for  A  to 
establish  precise  relationships. 

SL  is  a  very  general  language,  sufficiently  so  that  it  can  contain  well-formed  formulas  whose 
solutions  may  be  both  undecidable  and  NP-complete.  FIPA  recognizes  the  difficulties  such 
formulas  might  cause  and  specifies  three  subsets  of  SL.  SLO,  the  minimal  subset,  has  no 
identifying  reference  expressions,  and  allows  only  well-formed  fonnulas  without  quantifiers 
and  Boolean  operators.  SL1  extends  SLO  with  Boolean  operators,  facilitating  arbitrary  Boo¬ 
lean  expressions.  SL2  adds  to  SL1  identifying  reference  expressions,  and  also  restricted 
forms  of  existential  and  universal  quantification  to  propositions:  nested  quantifiers  are  not 
permitted  unless  the  containing  proposition  is  also  a  quantification.  This  and  other  restric¬ 
tions  (in  particular,  no  free  variables)  keep  SL2  expressions  decidable. 

SLO  is  useful  for  stating  simple  facts,  and  much  of  the  inter-agent  communication  in  the  IDA 
prototype  simulation  uses  SLO  as  the  content  language.  For  example,  the  enemy  organization 
agent  (specifically,  the  Recalculate  Position  Task)  uses  SLO  to  inform  the  SimState  agent  of 
its  position.  It  sends  a  message  using  the  Inform  communicative  act  with  content  such  as: 

((has-location  “1  (DA)  Mech  Bde”  (position  latitude  31.65  :longitude  -97.46))) 

The  enemy  organization  agent  establishes  “Geo-Position”  as  the  name  of  the  ontology  for 
this  message.  In  this  ontology,  has-location  and  position  have  meaning: 

•  Has-location  is  a  relationship  between  the  name  of  an  organization  and  a  geodetic 
coordinate.  This  relationship  can  easily  be  translated  to  elements  of  the  GH  ontology. 
Note,  however,  that  modeling  the  same  information  in  the  GH  ontology  requires  in¬ 
stances  of  ObjectltemLocation  and  ReportingData.  The  Geo-Position  ontology  is  more 
concise. 

•  Position  is  a  two-argument  function  that  generates  an  instance  of  class  GeoPosition.  In 
other  words,  it  encapsulates  the  specification  of  position. 
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The  enemy  agent  is  assuming  the  SimState  agent  understands  “Geo-Position”  as  an  ontology 
in  which  the  same  semantics  apply  to  these  two  terms. 

3.1.4.  Zeus 

The  prototype  uses  the  Zeus  parser-generator  to  convert  between  XML  documents  and  Java 
classes.  Zeus,  an  open-source  product  of  Enhydra,  takes  as  input  a  DTD  and  generates  as 
output  a  set  of  Java  classes.  The  input-output  relationship  may  be  summarized  as  follows: 

•  For  each  element  in  the  DTD,  Zeus  generates  an  interface  and  implementing  class 
whose  names  derive  from  that  element. 

•  For  each  attribute  of  an  element,  Zeus  generates  in  the  corresponding  interface  and 
implementing  class  a  get/set  method  pair.  The  result  of  the  get  method  (or  the  pa¬ 
rameter  of  a  set  method)  is  an  instance  of  java.lang. String. 

•  For  each  single-valued  or  optional  element  of  the  element  content,  Zeus  includes  a 
get/set  method  pair  in  the  element’s  interface  and  implementing  class.  The  get 
method  returns  an  instance  of  the  single-valued  element’s  interface. 

•  For  each  multiple-valued  element  (that  is,  an  element  specified  with  a  *  or  +)  in  the 
element  content,  Zeus  generates  a  get/set/add/remove  method  quadruple.  The  get 
method  returns  an  instance  of  java.util.List;  the  parameter  to  the  set  method  is  a  List, 
and  the  list  should  be  a  homogenous  list  of  instances  of  the  Java  interface  generated 
from  the  underlying  element.  The  add  and  remove  methods  both  take  a  single  pa¬ 
rameter  that  is  an  instance  of  the  underlying  element’s  interface. 

•  An  interface  specifies  methods  to  let  an  instance  marshal  itself  (and  the  implementing 
class  satisfies  the  specification).  Marshalling  means  to  turn  an  instance  into  a  valid 
XML  document.  Marshalling  methods  take  a  parameter  that  specifies  the  destination 
(file,  URL,  or  writer). 

•  Zeus  generates  a  class  containing  static  methods  to  unmarshal  the  root  element  of  the 
DTD,  specified  when  Zeus  is  executed.  Unmarshalling  is  the  opposite  of  marshalling. 
The  methods  take  as  a  parameter  a  source  file,  input  stream,  or  reader.  Each  method 
yields  an  instance  of  the  interface  generated  from  the  root  element. 

Some  unmarshalling  methods  have  a  Boolean  parameter  that  specifies  whether  to 
validate  the  XML  document.  If  Zeus  performs  validation,  it  will  throw  an  exception  if 
the  document  doesn’t  conform  to  its  DTD.  Conformance  is  syntactic:  All  required 
elements  must  be  present,  all  elements  must  be  in  the  correct  order,  all  attributes  must 
have  the  correct  values,  etc. 

Using  the  DTD  in  Figure  13  as  input,  for  example,  Zeus  generates  the  following  Java  code: 

•  Interfaces  LoaderConfig,  DBSpec,  EnemyOrgSpec,  and  FriendlyOrgSpec.  Zeus  would,  by 
default,  generate  interfaces  for  all  elements,  but  it  has  an  option  to  compress  elements 
that  only  contain  #PCDATA  into  strings,  and  the  IDA  prototype  simulation  uses  this 
option. 

•  Corresponding  classes  LoaderConfiglmpI,  DBSpecImpI,  EnemyOrgSpecImpI,  and 
FriendlyOrgSpecImpl. 

•  The  class  LoaderConfigUnmarshaller,  because  Loader-Config  is  specified  as  the  root  ele¬ 
ment. 

Zeus  is  an  excellent  tool  for  prototypes,  because  like  DTDs  it  is  small,  concise,  and  does 
what  it  can  efficiently  and  effectively.  It  should  be  used  with  care  in  production  systems  be- 
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cause  of  the  inherent  limitations  of  a  DTD  in  terms  of  XML  validation  capabilities.  For  in¬ 
stance,  the  DTD  in  Figure  13  shows  that  DB  is  an  attribute  of  the  Loader-Config  element,  and 
that  a  Loader-Config  may  contain  a  DB-Spec  element.  A  Loader-Config  should  contain  a  DB-Spec 
if  and  only  if  DB  has  the  value  “true”,  but  expressing  this  constraint  is  beyond  the  power  of  a 
DTD. 

3.2.  Technical  View:  Component  Agent  and  Task  Structure 

The  components  of  the  IDA  prototype  simulation  are  inherently  asynchronous.  The  different 
controllers  operate  independently.  None  are  constrained  to  each  other’s  timing.  The  major 
characteristic  all  components  share,  then,  is  the  need  for  independence.  A  secondary  charac¬ 
teristic  is  the  need  to  communicate  with  other  components,  even  if  their  existence  is  not 
known  until  run-time. 

These  considerations  call  for  implementation  technology  that  supports  unconstrained  and  ar¬ 
bitrary  communications.  Because  the  characteristics  are  essentially  those  of  agents,  and  be¬ 
cause  FIPA-OS  was  being  used  to  implement  agents,  the  prototype  implements  components 
as  agents,  handing  asynchronicity  and  communication  using  FIPA-OS  architecture  and 
methods.  Not  all  components  of  the  prototype  are  true  agents  that  register,  search,  and  infer. 
Nevertheless,  there  are  two  good  reasons  to  use  FIPA-OS  whenever  possible: 

1 .  Reuse  of  FIPA-OS  architecture  and  methods  obviates  the  need  for  extensive  design 
and  implementation. 

2.  FIPA-OS  includes  an  Agent  Loader  tool  (not  to  be  confused  with  the  Loader  compo¬ 
nent  of  the  IDA  prototype  simulation  discussed  in  Section  2.6)  that  can  be  used  to 
control  agent  start-up  and  shutdown.  The  Agent  Loader  invokes  each  new  agent  as  a 
new  thread  in  one  Java  virtual  machine.  Executing  a  Java  virtual  machine  that  ac¬ 
cesses  FIPA-OS,  Protege-2000,  and  an  RDBMS  is  computationally  expensive  -  it  re¬ 
quires  approximately  500  MB  of  RAM  -  so  use  of  the  Agent  Loader  significantly 
lessens  computer  resources  needed. 

Each  component  in  the  System  View  is  implemented  as  an  agent  or  (in  the  case  of  a  Friendly 
Organization)  a  set  of  agents  (this  does  not  include  the  RDBMS,  which  is  a  COTS  compo¬ 
nent).  Each  component  may  be  invoked  either  as  a  stand-alone  application  or  through  the 
Loader  (see  Section  2.6).  Except  for  friendly  organizations,  components  may  also  be  invoked 
through  the  FIPA-OS  Agent  Loader  tool. 

The  following  sections  cover  each  component’s  agent  and  task  structure. 

3.2.1.  Agent/Task  Structure  of  Enemy  Organization  Component 

The  Enemy  Organization  component  is  implemented  as  a  single  agent.  The  task  structure  of 
this  component  is  discussed  on  p.  B-21. 

3.2.2.  Agent/Task  Structure  of  Friendly  Organization  Component 

The  Friendly  Organization  component  is  implemented  as  a  set  of  agents  initiated  by  a  single 
application,  shown  in  Figure  19  as  the  Decision  Support  Application  (parallelograms  repre¬ 
sent  agents).  This  application  is  not  itself  an  agent,  for  reasons  discussed  below.  It  is  a  Java 
class  that  invokes  four  agents,  each  of  which  serves  a  distinct  role: 

1 .  The  Threat  Perception  Agent  is  responsible  for: 
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Figure  19.  Friendly  Organization  Agent  Structure 

a)  Identifying  threats  from  a  hostile  enemy  organization  to  any  friendly  organiza¬ 
tion  (not  just  the  one  associated  with  the  decision  support  application  that  in¬ 
voked  the  agent). 

b)  Notifying  the  Decision  Support  Application  of  the  threat,  thereby  giving  the 
application  the  opportunity  to  inform  decision  makers. 

c)  Notifying  all  Threat  Response  Agents  (not  just  the  one  associated  with  the  de¬ 
cision  support  application  that  invoked  the  agent)  of  the  threat. 

2.  The  Threat  Response  Agent  is  responsible  for: 

a)  Awaiting  receipt  of  threats. 

b)  Formulating  courses  of  action  that  might  be  used  to  respond  to  a  threat.  These 
courses  of  action  are  expressed  as  frames  in  the  GH  knowledge  base,  so  the 
agent  updates  the  knowledge  base  as  part  of  its  functionality. 

c)  Notifying  the  Decision  Support  Application  of  the  courses  of  action. 

3.  The  DB  Updater  Agent  is  responsible  for: 

a)  Detecting  changes  in  the  GH  data  set  associated  with  the  friendly  organiza¬ 
tion,  and  communicating  these  changes  to  all  other  known  DB  Updater 
Agents. 

b)  Receiving  changes  from  other  DB  Updater  Agents  and  incorporating  them 
into  the  GH  data  set. 

4.  The  Tasks  Agent  is  responsible  for  starting  and  controlling  certain  tasks  perfonned  by 
each  Friendly  Organization  component.  These  tasks  are  discussed  below. 

The  Tasks  Agent  is  not  a  true  agent.  It  does  not  communicate  with  other  agents.  Its 
accesses  to  the  knowledge  base  are  for  mundane  maintenance  chores.  It  is  imple- 
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mented  as  an  agent  because  a  friendly  organization  needs  to  perform  certain  tasks  pe¬ 
riodically,  and  because  a  FIPA-OS  agent  can  control  a  task  hierarchy. 

All  agents  in  a  single  Friendly  Organization  component  share  the  same  knowledge  base.  This 
decision  is  convenient  (the  KB  Updater  Agent  only  deals  with  a  single  knowledge  base,  and 
the  Threat  Perception  and  Response  Agents  can  be  assumed  to  have  identical  knowledge) 
and  efficient  (each  Protege-2000  knowledge  base  is  memory-intensive). 

The  Decision  Support  Application  does  not  access  the  knowledge  base  directly.  Only  agents 
access  the  knowledge  base  (this  is  a  design  decision).  The  Decision  Support  Application  re¬ 
ceives  infonnation  from  agents,  and  updates  the  GH-conformant  data  set.  Agents,  on  the 
other  hand,  focus  on  the  knowledge  base. 

3.2.2. 1.  Threat  Perception  Agent  Structure 

The  Threat  Perception  Agent  is  implemented  as  a  FIPA-OS  agent  whose  task  hierarchy  is 
shown  in  Figure  20.  The  agent  initiates  an  Idle  Task  that  serves  as  the  root  of  the  task  hierar¬ 
chy.  The  subtasks  are  as  follows: 

•  On  start-up,  the  Idle  Task  initiates  the  Ontology  Search  Task  and  the  Threat  Response 
Agent  Search  Task. 

•  The  Threat  Response  Agent  Search  Task  is  a  periodic  task  that  uses  the  Directory  Facili¬ 
tator  to  search  for  all  known  Threat  Response  Agents.  This  list  will  include  the  Threat 
Response  Agent  of  the  agent  running  this  search  task.  The  interval  between  searches 
(that  is,  the  duration  of  the  child  Wait  Task)  is  a  parameter  of  the  Friendly  Organiza¬ 
tion  component,  as  described  in  Section  2.2. 

•  The  Ontology  Search  Task  is  the  task  responsible  for  searching  the  knowledge  base  for 
threats.  In  other  words,  it  encapsulates  the  logic  and  rules  that  determine  what  consti¬ 
tutes  a  threat.  The  Ontology  Search  Task  also  detects  organizations  that  once  were  but 
no  longer  pose  a  threat.  It  is  a  periodic  task;  each  analysis  of  the  knowledge  base  and 
subsequent  wait  counts  as  one  cycle. 

•  Each  time  the  Ontology  Search  Task  detects  a  threat  or  a  canceled  threat,  it  initiates  an 
Inform  Threat  Response  Agents  Task  (thus  several  of  these  latter  tasks  may  be  executing 
simultaneously).  This  task  informs  every  agent  found  by  the  Threat  Response  Agent 


Figure  20.  Threat  Perception  Agent  Task  Structure 
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Search  Task  of  the  threat.  It  sends  a  message  expressed  in  SLO  of  the  form: 

((threat  hostile-org-name  threatened-friendly-org-name)) 
if  hostile-org-name  poses  a  threat,  and 

((not-threat  hostile-org-name  threatened-friendly-org-name)) 
if  it  no  longer  does. 

•  The  Inform  Threat  Response  Agents  Task  is  implemented  by  having  it  initiate  an  Inform 
Agents  Task.  The  latter  task  is  a  procedural  abstraction  defined  by  the  prototype.  It  is 
created  with  four  parameters:  a  list  of  agent  IDs,  infonnation,  the  name  of  a  language, 
and  the  name  of  an  ontology.  It  creates  a  FIPA  message  that  contains  the  information, 
language,  and  ontology,  sends  that  message  to  each  agent  in  the  list,  then  ends. 

3. 2. 2. 2.  Threat  Response  Agent  Structure 

The  Threat  Response  Agent  is  a  FIPA-OS  agent  whose  responsibility  is  to  formulate  courses 
of  action  in  response  to  infonnation  received  from  a  Threat  Perception  Agent.  It  is  initiated 
by  a  Friendly  Organization  component,  which  gives  it  a  reference  to  a  Decision  Support  Ap¬ 
plication  and  the  knowledge  base  that  component  is  using. 

A  Threat  Response  Agent’s  task  structure  is  implemented  as  a  single  Idle  Task  that  listens  for 
Inform  messages.  Assuming  an  Inform  message  has  the  correct  ontology  and  language,  the  Idle 
Task  will  interpret  the  message’s  contents.  Threat  content  interpretation  causes  the  generation 
of  a  list  of  courses  of  action.  The  Threat  Response  Agent  notifies  the  Decision  Support  Ap¬ 
plication  of  these  courses  of  action.  The  Decision  Support  Application  is  not  an  agent,  so  this 
notification  is  implemented  using  library  classes  from  the  Java  run-time  environment,  not 
FIPA-OS  classes. 

3. 2. 2. 3.  Tasks  Agent  Structure 

The  Tasks  Agent,  whose  structure  is  shown  in  Figure  21,  initiates  certain  tasks  that  are  nec¬ 
essary  during  the  execution  of  a  Friendly  Organization  component: 


Figure  21.  Tasks  Agent  Task  Structure 

•  It  initiates  the  tasks  that  simulate  the  intelligence  sources  a  friendly  organization  pos¬ 
sesses.  These  sources  include  human  intelligence;  in  fact,  human  intelligence  is  the 
only  intelligence  source  the  IDA  prototype  simulation  currently  implements. 

•  It  finds  the  executing  SimState  component  (this  is  necessary  before  intelligence 
sources  can  operate). 

•  It  initiates  a  task  that  performs  a  periodic  search  for  Overview  components.  Overview 
components  are  implemented  as  agents,  so  the  search  is  implemented  using  FIPA-OS 
agent  search  methods. 
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•  It  initiates  a  task  that  periodically  examines  the  GH-confonnant  data  set  for  changes, 
and  incorporates  these  changes  into  the  Knowledge  Base.  The  changes  are  then  visi¬ 
ble  to  all  agents  of  the  Friendly  Organization  component. 

Furthermore: 

•  An  instance  of  the  agent  may  be  instructed  to  request  that  all  known  Overview  Agents 
highlight  the  location  of  the  Friendly  Organization  controlling  the  agent.  This  is  the 
purpose  of  the  “Flash  Location”  button  in  Figure  5.  (That  the  button  is  deactivated  in 
Figure  5  means  no  Overview  components  have  been  found.)  When  a  decision  maker 
clicks  the  button,  the  decision  support  application  signals  the  Tasks  agent  to  perform 
the  “flash”  request.  The  request  is  carried  out  by  the  agent;  it  involves  no  tasks.  FIPA- 
OS  agents  can  send  messages  too. 

All  tasks  are  periodic.  The  Human  Intel  Task’s  delay  is  based  on  a  Poisson  distribution,  a  rec¬ 
ognition  that  humans  do  not  provide  intelligence  on  a  regular  basis.  (This  is  not  to  claim  that 
a  Poisson  distribution  is  a  comprehensive  or  even  realistic  model  of  human  behavior.) 

The  SimState  Agent  Search  Task  only  executes  until  it  finds  the  SimState  component.  When  it 
does,  it  tenninates.  Other  tasks  run  until  the  Friendly  Organization  component  terminates. 

3. 2. 2. 4.  DB  Updater  Agent  Structure 

The  DB  Updater  Agent  is  responsible  for  ensuring  database  concurrency:  a  change  to  one 
Generic  Hub  data  set  must  be  propagated  to  all  others.  Database  concurrency  is  a  highly 
complex  area,  but  it  is  straightforward  in  this  prototype  simulation  because  the  initial  Generic 
Hub  data  set  content  is  never  modified.  The  decision  support  application  adds  rows,  only  un¬ 
der  tight  constraints.  An  update  to  a  GH  data  set  always  consists  of: 

1.  Adding  a  record  to  the  REPORTING-DATA  table,  and  a  corresponding  record  to  the 
REPORTING-DATA-ABSOLUTE-TIMING  table. 

2.  Adding  a  record  to  one  of  several  tables  that  have  a  column  for  which  a  reporting-data- 
id  is  a  foreign  key  (OBJECT-ITEM-LOCATION,  OBJECT-ITEM-ASSOCIATION,  etc.). 

An  update  will  sometimes  include: 

3.  Adding  rows  to  other  tables  (LOCATION,  etc.)  to  which  the  second  table  has  an  integrity 
constraint. 

Two  RDBMSs  never  attempt  to  lock  the  same  information. 

Figure  22  shows  the  task  structure  of  the  DB  Updater  Agent.  The  root  Idle  Task  initiates  a  pe¬ 
riodic  task,  DB  Update  Agent  Search  Task,  that  locates  all  known  DB  Updater  Agents.  This  task 
uses  the  Agent  Search  Task  procedural  abstraction,  using  the  string  “db-upd”  as  the  type  of 
agent  for  which  to  search.  The  interval  between  searches  is  a  parameter  of  a  Friendly  Organi¬ 
zation  component  that  may  be  specified  on  start-up. 

The  DB  Updater  Agent  also  has  two  important  methods: 

1.  Its  handlelnformQ  method  listens  for  messages  with  the  INFORM  performative.  These 
messages  are  expected  to  come  from  other  DB  Updater  Agents.  They  inform  an  agent 
of  updates  to  a  GH-confonnant  data  set.  When  such  a  message  is  received, 
handlelnformQ  parses  the  message  and  uses  its  content  as  a  set  of  updates. 

2.  Other  agents  or  applications  may  invoke  its  propagateChanges()  to  propagate  a  set  of 
updates  to  all  other  DB  Updater  Agents  found  by  the  DB  Update  Agent  Search  Task. 
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Figure  22.  DB  Update  Agent  Task  Structure 

The  content  of  messages  sent  by  the  DB  Updater  Agents  is  a  list  of  SQL  queries.  This  is  not  a 
good  format;  for  one  thing,  it  ties  the  prototype  to  a  particular  implementation  of  SQL. 
Transmitting  the  updates  as  an  XML  document  that  map  to  rows  in  the  GH-data  model  is 
considered  a  better  approach,  but  was  not  used  in  the  IDA  prototype  simulation  because  it 
would  have  taken  more  time  to  implement  than  was  available. 

3.2.3.  Agent/Task  Structure  of  Overview  Component 

The  Overview  component  is  implemented  as  a  FIPA-OS  agent  whose  role  is  to  listen  for 
messages  with  INFORM  or  REQUEST  performatives.  An  INFORM  performative  is  a  notification  of 
change  in  state.  Currently,  state  captures  only  the  location  of  a  battlefield  object.  The  mes¬ 
sage,  which  is  from  the  SimState  Agent,  gives  the  object’s  name  and  location.  The  Idle  Task 
will  request  the  GUI  of  the  Overview  component  to  change  the  location  of  the  object.  If  the 
object  did  not  exist,  it  is  displayed;  if  the  new  location  is  outside  the  bounds  of  the  display,  it 
is  removed  from  the  display. 

The  REQUEST  message  occurs  when  the  controller  of  a  friendly  or  hostile  organization  clicks 
the  Flash  Location  button  on  that  organization’s  user  interface.  The  message  will  contain  the 
name  of  a  battlefield  object.  If  the  GUI  of  the  Overview  component  is  currently  displaying 
this  object,  it  will  change  the  display  to  highlight  the  object’s  position. 

3.2.4.  Agent/Task  Structure  of  SimState  Component 

The  SimState  component  is  implemented  as  a  FIPA-OS  agent  whose  primary  role  is  to  main¬ 
tain  ground  truth  regarding  the  physical  state  of  battlefield  objects.  The  agent  invokes  an  Idle 
Task  that  listens  for  messages  with  INFORM  and  REQUEST  performatives.  An  INFORM  performa¬ 
tive  is  expected  to  contain  a  specification  of  new  state  infonnation  for  a  battlefield  object. 
Currently,  hostile  organization  components  send  these  messages  regarding  their  location.  The 
SimState  agent  makes  no  reply  to  these  messages. 

A  REQUEST  performative  is  expected  to  specify  a  geographic  area.  The  SimState  agent  replies 
with  a  list  of  the  names  and  locations  of  all  battlefield  objects  within  the  area.  The  position  of 
these  objects  is  originally  determined  by  the  content  of  the  GH-confonnant  data  set  specified 
during  initialization  of  the  prototype  simulation.  Positions  are  updated  by  subsequent  INFORM 
messages.  The  intent  is  to  simulate  sensor  behavior:  a  given  sensor  is  able  to  detect  battle¬ 
field  objects  within  a  prespecified  range.  Currently  the  prototype  simulation  implements  only 
human  sensors  (i.e.,  battlefield  observers)  who  are  able  to  detect  objects  within  a  rectangular 
area  that  has  no  obstacles.  This  model  is  overly  simplistic  but  is  easy  to  implement. 
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In  addition  to  handling  messages,  the  SimState  agent  also  notifies  Overview  agents  of  state 
changes.  The  SimState  agent  performs  this  function  each  time  it  receives  a  state  change.  The 
agent  therefore  searches  for  Overview  agents  and  maintains  a  list  of  all  agents  found  during 
the  last  search.  Figure  23  shows  the  task  structure  that  the  SimState  agent  uses  to  perform 
this  search.  The  Find  Overview  Agents  Task  is  a  periodic  task. 


Figure  23.  SimState  Agent  Task  Structure 

3.2.5.  Agent/Task  Structure  of  Loader  Component 

The  Loader  component  is  implemented  as  a  FIPA-OS  agent.  However,  it  is  not  truly  an 
agent.  The  implementation  strategy  permits  it  to  be  controlled  from  the  FIPA-OS  Agent 
Loader  tool,  thereby  conserving  system  resources. 

The  Loader  agent  invokes  no  tasks.  It  only  initiates  other  agents,  after  which  it  displays  a 
GUI  that  a  controller  may  use  to  start  enemy  organization  movement,  or  to  stop  execution  of 
all  running  components. 

3.3.  Inter- Agent  Messages 


Table  1  shows  the  types  of  messages  agents  in  this  system  send  to  each  other. 
_ _  Table  1.  Message  Types  Sent  By  Agents _ _ 


Sending 

Agent 

Receiving 

Agent 

Language 

Ontology 

Performative 

Protocol 

Enemy  Or¬ 
ganization 

Overview 

identify 

Request 

No- Protocol 

Syntax:  flash  obj-item-name 

SimState 

SLO 

geo-position 

Inform 

No- Protocol 

Syntax: 

((has-location  org-name  (position  latitude  lat  :longitude  Ion))) 

DB 

Updater 

DB 

Updater 

binary 

db-update 

Inform 

No- Protocol 

Syntax:  An  instance  of  class  java. util. List;  each  list  element  is  a 
string  that  is  a  syntactically  valid  SQL  INSERT  statement. 

Threat 

Perception 

Threat 

Response 

SLO 

threat 

Inform 

No- Protocol 

Syntax:  One  of: 

•  ((threat  obj-item-name-1  obj-item-name-2)) 

•  ((not-threat  obj-item-name-1  obj-item-name-2)) 

Tasks 

SimState 

SLO 

geo-position 

Request 

Request-Reply- 

Protocol 

B-34 


Sending 

Agent 

Receiving 

Agent 

Language 

Ontology 

Performative 

Protocol 

Syntax: 

((action  simstate-agent-name 
(sensing 

:center  (position  latitude  lat-1  :longitude  Ion-1) 

:northwest  (position  latitude  lat-2  :longitude  Ion-2)))) 

Overview 

identify 

Request 

No- Protocol 

Syntax:  flash  obj-item-name 

SimState 

Overview 

Inform 

No- Protocol 

Syntax:  An  instance  of  class  ida.sd.gpc.GeoPositionlmpl. 

Tasks 

SLO 

geo-position 

Inform 

Request-Reply- 

Protocol 

Syntax: 

((result 

(action  simstate-agent-name 
(sensing 

:center  (position  latitude  lat-1  :longitude  Ion-1) 
:northwest  (position  latitude  lat-2  :longitude  Ion-2))) 
(set  (position  latitude  lat  :longitude  Ion  :name  n)  ...))) 

The  following  points  should  be  noted: 

•  The  “identify”  language  used  by  the  Overview  agent  was  invented  for  this  system. 
The  language  contains  only  one  valid  sentence:  flash  n,  where  n  is  the  name  of  a  bat¬ 
tlefield  object.  The  merits  of  using  an  arbitrary  language  are  debatable.  On  the  one 
hand,  the  language  can  be  concise.  On  the  other  hand,  message  interpretation  be¬ 
comes  system  dependent. 

The  message  could  also  be  expressed  using  SLO  with  a  REQUEST  perfonnative: 

((action  overview-agent-id  (flash  obj -item-name)) 

However,  parsing  the  content  to  extract  the  action  requires  much  more  effort  than  the 
customized  language.  SLO,  while  preferable  for  a  production  system,  can  be  expen¬ 
sive  for  a  prototype,  and  its  use  should  be  considered  carefully. 

•  FIPA-OS  permits  binary  objects  -  specifically,  instances  of  Java  classes  that  imple¬ 
ment  interface  java.io. Serializable  -  as  message  content.  A  few  agents  of  the  prototype 
(DBUpdater  and  SimState)  send  messages  with  binary  content.  In  a  production  sys¬ 
tem,  the  decision  to  use  binary  content  should  not  be  made  lightly.  It  presumes  the 
sending  and  receiving  agent  have  access  to  the  same  Java  class;  in  other  words,  it  pre¬ 
sumes  certain  standardization  efforts.  Standardization  is  desirable  but  also  costly. 
Textual  message  content  transmitted  using  a  standard  language  is  preferable. 

•  The  majority  of  inter-agent  communication  occurs  using  the  No-Protocol  protocol, 
meaning  the  sending  agent  does  not  expect  a  response  from  the  receiver.  This  is 
probably  inappropriate  for  a  production  system.  Then  again,  for  many  of  the  mes¬ 
sages  it  is  not  clear  that  the  sender  would  behave  any  differently  if  the  receiver  failed 
to  receive,  or  refused  to  accept,  a  message. 
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•  Some  messages  lack  an  ontology;  some  lack  both  a  language  and  an  ontology.  This  is 
probably  a  mistake  for  a  production  system. 

•  Table  1  does  not  include  the  agent  registration/deregistration  and  agent  search  mes¬ 
sages  are  sent  to  FIPA-OS  tools.  FIPA  specifications  (see  [FIPA-70],  p.  B-33)  govern 
their  content. 

3.4.  Use  of  Model- View  Controller  Paradigm 

Most  components  of  the  IDA  prototype  simulation  utilize  the  Model-View-Controller  (MVC) 
paradigm  popularized  by  the  Smalltalk  language  [Smalltalk  1983].  This  paradigm  is  espe¬ 
cially  useful  for  designing  and  implementing  applications  with  a  GUI.  Java  supports  it 
through  two  standard  library  components:  the  java.util.  Observable  class  and  the 
java.util. Observer  interface.  An  Observable  instance  may  have  observers  (instances  of  Ob¬ 
server);  the  Observable  may  then  invoke  a  method  that  automatically  signals  all  observers.  A 
GUI  component  commonly  uses  this  paradigm  to  signal  some  other  component  that  a  button 
has  been  pressed,  a  text  field  has  changed,  etc. 

The  MVC  paradigm  decouples  an  application’s  functionality  from  its  user  interface.  Methods 
in  classes  implementing  the  user  interface: 

1 .  Respond  to  user  actions. 

2.  Are  invoked  by  methods  in  other  classes  to  display  infonnation.  Their  functionality  is 
concerned  with  the  format  of  the  information,  not  with  its  meaning. 

Other  classes  are  concerned  with  a  component’s  essential  functionality:  the  transformation  of 
user  inputs  into  outputs  to  display  or  communicate. 

The  IDA  prototype  simulation  components  contain  at  least  two  Java  classes:  one  to  imple¬ 
ment  the  functionality,  and  another  to  implement  the  user  interface.  Figure  24  shows  classes 
for  the  Enemy  Organization  component  that  implement  the  MVC  paradigm.  Class 
EnemyOrganisationGUI  contains  fields  that  are  used  to  display  values  to  the  user.  Since  most  of 
these  values  are  textual  (see  Figure  3),  they  are  of  type  javax.swing.JTextField.  Fields  JsMoving 


o 


Observer 


update(o  :  Observable,  arg  :  Object) 

A 


Figure  24.  Model-View-Controller  Paradigm  Example  for  Enemy  Organisation 


EnemyOrganisation 


^  EnemyOrganisation(gh5kb  :  GH5KB, 
agentName  :  String, 
orgName  :  String, 
bearing  Angle  :  Double, 
speed  :  Double, 
posit  ion  Refresh  Rate  :  Integer, 
displayGUI  :  Boolean) 


EnemyOrganisationGUI 

-  organisation  :  JTextField 
b;  angle  :  JTextField 
§>  -  speed  :  JTextField 
ea;  JsMoving  :  JCheckBox 
.  flashLocation  :  JButton 

^  EnemyOrganisationGUI(orgName  :  String, 

o  :  Observer) 

^  setPosition(lat :  Double,  Ion  :  Double) 

^  getLatitude() :  Double 
^  getSpeed() :  Double 
^  setSpeed(speed  :  Double) 

^  getBearingAngle() :  Double 
^  setBearingAngle(bearingAngle  :  Double) 

^  getPositionRefreshRate() :  Integer 
1  setPositionRefreshRate(rate  :  Integer) 
getOrgName() :  String 
*  setFlashCapability(enabled  :  Boolean) 

^  setlsMovingDisplay(isMoving  :  Boolean) 
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and  _flashLocation  illustrate  the  other  two  user  interface  paradigms  used. 

Most  methods  of  EnemyOrganisationGUI  are  set/get  methods  that  access  the  user-visible  prop¬ 
erties.  (Properties  that  are  read-only,  such  as  the  organization’s  name,  are  fixed  by  the  con¬ 
structor  and  cannot  be  set.)  The  class  constructor  is  responsible  for  setting  the  fields,  and  for 
defining  the  Java  events  and  event  handlers  that  occur  in  response  to  user  interface  events. 
These  event  handlers  invoke  the  update()  method  of  the  observer  given  to  the 
EnemyOrganisationGUI()  constructor.  When  EnemyOrganisation  is  instantiated,  it  instantiates 
EnemyOrganisationGUI,  passing  itself  as  the  value  of  the  new  object  o.  Thus  the  update() 
method  invoked  is  that  of  EnemyOrganisation.  The  update()  method  analyzes  its  arg  parameter 
to  determine  the  nature  of  the  update,  responds  appropriately,  and  invokes  set  methods  of  the 
EnemyOrganisationGUI  instance.  See  Figure  25. 


Figure  25.  Sample  MVC  Event  Sequence  for  Enemy  Organisation 

3.5.  Modularization 

The  IDA  prototype  simulation  is  decomposed  into  modules  according  to  the  principle  of  in¬ 
formation  hiding:  Each  module  encapsulates  a  set  of  secrets  not  visible  to  other  modules 
[Parnas  1972].  The  modules  are  represented  as  four  trees: 

1 .  The  Environment  Hiding  module,  the  primary  secrets  of  which  are  the  interfaces  be¬ 
tween  the  other  two  modules  and  the  environment  in  which  the  prototype  simulation 
executes.  Changes  to  the  Environment  Hiding  module  are  motivated  by  updates  to 
hardware  and  software  technologies. 

2.  The  Behavior  Hiding  module,  the  primary  secret  of  which  is  the  system  functionality. 
Changes  to  the  Behavior  Hiding  module  are  motivated  by  additions  or  modifications 
to  system  features,  or  to  changes  in  the  user  interface.  (In  a  production  system, 
changes  to  the  Behavior  Hiding  module  stem  from  changes  to  system  requirements, 
but  the  IDA  prototype  simulation  has  no  formally  defined  requirements.) 

3.  The  Software  Decision  module,  which  encapsulates  physical  facts,  theories,  and  data 
and  procedural  abstractions.  Changes  to  the  Software  Decision  module  are  motivated 
by  perceived  improvements  in  execution  speed  and  design  clarity. 

4.  The  Software  Generation  module,  which  encapsulates  packages  that  assist  in  code 
generation.  The  primary  secrets  of  this  module  are  decisions  on  the  most  effective 
way  to  specify  certain  aspects  of  functionality  in  non-native  languages.  The  secon¬ 
dary  secrets  are  the  algorithms  and  data  structures  used  in  processing  those  languages. 
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Changes  to  the  Software  Generation  module  are  motivated  by  new  ideas  on  how  to 
represent  behavior  and  functionality. 

Each  of  these  modules  is  in  turn  decomposed  into  sub-modules,  each  with  its  own  secrets. 
This  decomposition  continues  until  the  designer  decides  that  a  module’s  secret  cannot  prof¬ 
itably  be  split  among  sub-modules.  At  that  point,  the  designer  implements  the  module’s  se¬ 
crets  in  Java.  Note  that  interior  nodes  of  the  tree  are  virtual  modules.  Only  leaf  nodes  are 
Java  classes. 

The  prototype’s  decomposition  follows  that  pioneered  in  the  development  of  software  for  the 
A-7E  [Britton  1986].  Java  packages  and  classes  replace  modules. 

Figure  26  shows  the  decomposition  of  the  prototype  system  into  packages  using  the  informa¬ 
tion  hiding  principle.  Figure  26  shows  only  the  packages  (i.e.,  the  interior  nodes);  selected 
classes  are  discussed  in  Section  3.6.  The  following  discussion  of  each  package  covers  the 
package’s  secrets  and  likely  motivation  for  change. 

3.5.1.  Environment  Hiding  Package 

The  Environment  Hiding  package  contains  subpackages  and  classes  that  encapsulate  the  en¬ 
vironment  in  which  the  system  operates.  The  secrets  of  this  package  are  imposed  by  the  de¬ 
signers  of  environmental  components,  and  are,  therefore,  external.  Changes  in  this  package 
occur  as  a  result  of  updates  to  the  environment,  usually  to  fix  bugs,  add  features,  or  effect 
performance  improvements.  Because  the  IDA  prototype  simulation  is  implemented  in  Java, 
environment  updates  will  be  updates  to  software  rather  than  hardware  components. 


Figure  26.  Information  Hiding  Structure  for  Prototype  System 
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The  secrets  of  Environment  Hiding  subpackages  are  almost  invariably  the  algorithms  and 
data  structures  used  to  implement  the  packages.  This  reflects  a  desire  to  present  the  subpack¬ 
age’s  functionality  through  an  API.  That  these  packages  will  be  reused  through  extension  is 
not  anticipated. 

The  usual  approach  to  creating  subpackages  of  Environment  Hiding  is  to  write  code  that  iso¬ 
lates  the  rest  of  the  system  from  change.  The  IDA  prototype  simulation  is  built  using  soft¬ 
ware  systems  that  are  relatively  stable.  Major  change  in  them  seems  unlikely.  Therefore, 
these  systems  are  the  Environment  Hiding  subpackages.  This  approach  is  untenable  in  pro¬ 
duction  systems,  for  reasons  discussed  in  the  some  of  the  following  subsections. 

3.5. 1.1.  Java 

The  Java  package  encapsulates  the  language  in  which  the  prototype  is  written,  and  the  stan¬ 
dard  libraries  available  to  interface  with  the  environment  in  which  the  prototype  runs.  The 
prototype  assumes  the  capabilities  present  in  version  1.4.1.  The  primary  secrets  of  this  pack¬ 
age  are  the  implementation  of  the  Java  Compiler,  the  Java  Virtual  Machine,  and  the  Java  run¬ 
time  libraries.  Changes  to  this  package  are  in  response  to  new  releases  of  Java  from  Sun  Mi¬ 
crosystems. 

3.5. 1.2.  FIPA 

The  FIPA  package  contains  subpackages  and  classes  that  encapsulate  an  implementation  of 
FIPA  specifications  for  agent-based  systems.  The  primary  secrets  of  this  package  are: 

•  The  algorithms  and  data  structures  used  to  implement  FIPA  specifications. 

•  The  underlying  technologies  used  to  implement  inter-agent  communication. 

The  prototype  uses  FIPA-OS  as  the  implementation  of  the  FIPA  package.  Agent-based  im¬ 
plementation  technologies  are  complex,  and  even  two  technologies  that  implement  FIPA  are 
likely  to  differ  greatly  based  on  arbitrary  design  decisions.  A  production  system  is  likely  to 
select  a  single  agent-based  implementation  technology,  as  opposed  to  trying  to  isolate  other 
modules  from  switches  between  different  technologies.  Therefore,  changes  in  this  package 
result  from  new  releases  of  FIPA-OS. 

3.5.1. 3.  RDBMS 

The  DBMS  package  encapsulates  an  implementation  of  a  database  management  system.  The 
primary  secrets  of  this  package  are  the  algorithms,  data  structures,  and  external  file  system 
structures  used  to  implement  that  RDBMS. 

The  IDA  prototype  simulation  was  tested  with  both  version  9i  of  Oracle  (personal  edition) 
and  version  4.0.17  of  MySQF  as  the  corresponding  RDBMS.  Use  of  a  particular  DBMS  is 
somewhat  hidden  by  Java’s  java.sql  library  package,  which  aside  from  a  single  vendor- 
specific  driver  module  is  supposed  to  reduce  variations  between  RDBMSs  to  differences  in 
their  implementations  of  SQF.  In  practice,  each  RDBMS  has  its  own  quirks  (for  example, 
Oracle  and  MySQF  give  different  initialization  sequences  in  their  documentation)  that  make 
RDBMS  encapsulation  if  not  problematic  then  at  least  time-consuming.  A  production  system 
will  want  to  devote  more  effort  to  RDBMS  encapsulation  than  the  IDA  prototype  simulation 
has.  Then  too,  each  RDBMS  implementation  offers  a  distinct  subset  or  superset  of  the  stan¬ 
dard  SQF-92  specification.  A  system’s  designer  must  consider  whether  particular  non¬ 
standard  features  are  important  and  consider  the  consequences  of  tying  his  system  to  a  spe¬ 
cific  RDBMS  by  using  them. 
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3.5. 1.4.  OKBC 

The  OKBC  package  encapsulates  an  implementation  of  an  OKBC  knowledge  base.  OKBC  is 
a  protocol,  so  this  package  defines  a  protocol  for  communicating  with  a  knowledge  base.  The 
primary  secrets  of  this  package  are  the  algorithms,  data  structures,  and  external  file  structures 
used  to  represent  a  knowledge  base.  Changes  in  this  package  are  in  response  to  changes  in 
the  technology  used  to  implement  OKBC. 

The  prototype  uses  Protege-2000  to  implement  the  OKBC  package.  Defining  an  abstraction 
of  OKBC  capabilities  is  not  difficult  (the  IDA  prototype  simulation  does  so  -  see  Sec¬ 
tion  3. 5. 3. 7)  and  a  production  system  should  consider  taking  this  step  to  isolate  other  pack¬ 
ages  from  the  effects  of  switching  between  OKBC  implementations. 

3. 5. 1.4.1.  Inferencing  Package 

The  Inferencing  package  encapsulates  rule-based  analysis  of  a  knowledge  base.  The  primary 
secrets  of  this  package  are  the  algorithms  and  data  structures  used  to  implement  rule-based 
analysis. 

The  prototype  uses  Algernon  as  the  Inferencing  package.  A  production  system  should  isolate 
changes  in  inferencing  technology  by  considering  the  inferencing  capabilities  needed  and 
writing  a  package  that  presents  an  interface  to  exactly  those  capabilities,  with  an  implementa¬ 
tion  in  terms  of  Algernon  or  another  suitable  inferencing  system. 

3. 5. 1. 4.2.  Constraints  Package 

The  constraints  package  encapsulates  constraint  enforcement  on  a  knowledge  base.  The  pri¬ 
mary  secrets  of  this  package  are  the  algorithms  and  data  structures  used  to  implement  con¬ 
straint  enforcement. 

The  prototype  uses  Protege-2000 ’s  PAL  (Protege-2000  Axiomatic  Language)  plug-in  to  im¬ 
plement  constraint  enforcement.  Constraint  enforcement  languages  differ  so  widely  that  iso¬ 
lating  change  between  them  may  prove  impractical.  Designers  of  a  production  system  should 
consider  selecting  a  specific  constraints  package  that  accompanies  the  OKBC  implementa¬ 
tion  they  choose. 

3.5. 1.5.  XML  Marshalling 

The  XML  Marshalling  package  encapsulates  how  Java  objects  may  be  marshaled  into  XML 
documents  (and  conversely,  how  XML  documents  may  be  unmarshalled  into  Java  objects). 
The  primary  secrets  of  this  package  are  the  algorithms,  data  structures,  and  external  file  sys¬ 
tem  access  techniques  used  to  implement  marshalling  and  unmarshalling  operations.  Changes 
to  this  package  are  likely  to  be  motivated  by  a  desire  to  improve  marshalling  functionality. 

The  prototype  uses  outputs  of  Zeus  to  implement  this  package.  Zeus  generates  a  set  of  classes 
and  interfaces  according  to  logical  and  conventional,  but  nevertheless  arbitrary,  rules.  These 
rules  are  part  of  the  XML  marshalling  package.  Other  marshalling  technologies  may  differ. 
Designers  of  a  production  system  should  consider  whether  a  more  robust  encapsulation  of 
marshalling  operations  is  desirable. 

Zeus  determines  XML  document  conformance  using  DTDs  rather  than  XSDs.  XSDs  add 
specification  power  that  might  result  in  some  documents  being  acceptable  to  Zeus  but  not  to 
other  technologies.  Designers  should  consider  whether  DTDs  meet  their  needs. 
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3.5.2.  Behavior  Hiding  Package 

The  Behavior  Hiding  package  contains  subpackages  and  classes  that  encapsulate  the  required 
behavior  of  the  system.  This  required  behavior  is  the  primary  secret  of  this  model.  Changes 
in  this  package  occur  as  a  result  of  a  desire  to  modify  or  extend  required  behavior. 

3.5.2. 1.  Closely  Related  Outputs  Package 

The  cro  package  consists  of  a  set  of  packages  that  individually  control  a  set  of  closely  related 
outputs.4  These  outputs  are  information  that  is  displayed  to  a  user  on  a  GUI,  messages  sent  to 
other  agents,  or  updates  to  a  Generic  Hub  data  set.  The  primary  secrets  of  the  Individuals 
package  are  the  rules  determining  the  timing,  order,  and  values  of  the  outputs.  Changes  in 
this  package  occur  in  response  to  required  changes  in  these  rules. 

3. 5.2. 1. 1.  Friendly  Organization 

The  friendlyorg  package  contains  subpackages  and  classes  that  implement  the  prescribed  func¬ 
tionality  of  the  Friendly  Organization  component.  The  primary  secret  of  this  package  is  that 
functionality.  The  secondary  secrets  are  the  algorithms  and  data  structures  used  to  implement 
that  functionality.  Changes  in  this  package  occur  in  response  to  required  changes  in  friendly 
organization  functionality. 

3. 5. 2.1.2.  Enemy  Organiza  tion 

The  enemyorg  package  contains  classes  that  implement  the  prescribed  functionality  of  the  En¬ 
emy  Organization  component.  The  primary  secret  of  this  package  is  that  functionality.  The 
secondary  secrets  are  the  algorithms  and  data  structures  used  to  implement  that  functionality. 
Changes  in  this  package  occur  in  response  to  required  changes  in  enemy  organization  func¬ 
tionality. 

3.5.2. 1.3.  Loader 

The  loader  package  contains  subpackages  and  classes  that  implement  the  prescribed  function¬ 
ality  to  interpret  a  simulation  configuration  and  load  a  simulation  based  on  that  configuration. 
The  primary  secret  of  this  package  is  the  content  of  a  configuration.  The  secondary  secrets 
are  the  algorithms  and  data  structures  used  to  convert  it  into  a  simulation.  Changes  in  this 
package  occur  in  response  to  changes  in  the  specification  of  a  configuration. 

3. 5.2.1. 4.  Overvie  w 

The  overview  package  contains  classes  that  implement  the  prescribed  functionality  of  the 
Overview  component.  The  primary  secret  of  this  package  is  the  format  in  which  the  informa¬ 
tion  is  presented.  The  secondary  secrets  are  the  algorithms  and  data  structures  used  to  receive 
requests  and  display  information.  Changes  in  this  package  occur  in  response  to  changes  in 
the  specification  of  how  an  overview  is  presented  to  a  controller. 

3. 5.2.1. 5.  SimSta  te 

The  simstate  package  encapsulates  classes  that  implement  ground  truth.  The  primary  secrets 
of  this  package  are  the  algorithms  and  data  structure  used  to  collect,  maintain,  and  dissemi¬ 
nate  ground  truth.  Changes  in  this  package  are  likely  to  occur  in  response  to  changes  in  what 
constitutes  ground  truth. 


4  The  A-7E  name  for  this  package,  “Function  Driver”,  seems  better  suited  to  real-time  systems. 
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3. 5. 2. 2.  Shared  Services  Package 

The  SS  package  encapsulates  aspects  of  behavior  common  to  several  Individuals  subpack¬ 
ages.  If  there  is  a  change  in  an  aspect  of  this  behavior,  it  is  likely  to  affect  all  subpackages. 
Each  component  of  SS,  then,  encapsulates  an  aspect  of  behavior  shared  by  at  least  two  sub¬ 
packages  of  the  cro  package. 

3. 5.2.2. 1.  FIPA 

The  fipa  package  encapsulates  shared  services  required  for  FIPA-based  agents  to  interact  with 
their  environment.  The  primary  secrets  of  this  package  are  the  FIPA  rules  for  performing  the 
services.  Changes  in  this  package  are  likely  to  be  motivated  by  changes  in  these  rules. 

3. 5. 2. 2. 2.  Protocol 

The  protocol  package  encapsulates  system-defined  protocols  used  in  inter-agent  communica¬ 
tions.  The  primary  secret  of  this  package  is  a  protocol’s  implementation.  Changes  in  this 
package  are  likely  to  occur  in  response  to  the  need  to  add  or  modify  protocols. 

3.5.3.  Software  Decision  Package 

The  Software  Decision  package  encapsulates  subpackages  and  classes  that  implement  soft¬ 
ware  design  decisions  based  on  physical  facts  (e.g.,  the  Earth’s  radius),  theories,  and  data  and 
procedural  abstractions.  The  secrets  of  this  package  come  not  from  prescribed  functionality 
or  environment  considerations  but  from  considerations  of  design,  implementation,  and  testing 
ease,  and  run-time  efficiency.  These  secrets  are  determined  by  software  designers.  Changes 
are  usually  motivated  by  a  desire  to  improve  either  performance,  or  to  simplify  or  clarify 
software  design. 

3.5.3. 1.  ADT 

The  adt  (abstract  data  type)  package  encapsulates  subpackages  and  classes  data  abstractions 
deemed  useful  throughout  the  system.  These  abstractions  do  not  implement  any  concepts  di¬ 
rectly  prescribed  by  system  functionality.  They  provide  lower  level  support  entities.  The  pri¬ 
mary  secrets  of  this  package  are  the  algorithms  and  data  structures  used  to  implement  the 
data  abstractions.  Changes  in  this  package  generally  result  from  a  realization  of  how  to  im¬ 
prove  performance. 

3. 5. 3. 2.  Algernon 

The  algemon  package  encapsulates  classes  that  provide  procedural  abstractions  used  by  other 
packages  to  deal  with  the  inference  subpackage  of  Environment  Hiding  (Section  3. 5. 1.4.1). 
The  secrets  of  this  package  are  the  algorithms  that  implement  those  procedural  abstractions. 
Changes  in  this  package  usually  result  from  a  realization  of  how  to  improve  performance. 
Extensions  to  this  package  result  from  observation  of  repeated  code  dealing  with  Algernon, 
or  from  realization  of  how  the  introduction  of  a  procedural  abstraction  could  clarify  code. 

3. 5. 3. 3.  FIPA 

The  FIPA  package  encapsulates  subpackages  and  classes  that  provide  procedural  and  data  ab¬ 
stractions  to  deal  with  concepts  in  the  fipa  subpackage  of  Environment  Hiding  (Sec¬ 
tion  3.5. 1.2).  This  package  does  not  encapsulate  either  FIPA  or  FIPA-OS.  It  just  simplifies 
use  of  FIPA-OS  through  the  introduction  of  these  abstractions.  The  secrets  of  this  package 
are  the  algorithms  and  data  structures  used  to  implement  the  abstractions.  Changes  in  this 
package  are  likely  to  be  motivated  by  a  realization  of  how  to  improve  perfonnance.  Exten¬ 
sions  to  this  package  result  from  observation  of  repeated  code  dealing  with  FIPA-OS,  or 
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from  realization  of  how  the  introduction  of  a  procedural  abstraction  could  clarify  code. 
Changes  and  extensions  may  also  result  from  upgrades  to  FIPA-OS  that  provide  new  capa¬ 
bilities. 

3. 5. 3. 4.  GH5  Ontology 

The  gh5ontology  package  tailors  the  ontology  package  (Section  3. 5. 3. 7)  to  support  manipula¬ 
tion  of  a  Generic  Hub  knowledge  base.  Methods  in  this  package  hide  design  decisions  on  the 
implementation  of  the  GH  ontology.  They  provide  some  procedural  abstractions  that  simplify 
access  to  the  ontology  as  a  consequence.  The  primary  secrets  of  this  package  are: 

•  The  use  of  Protege-2000  as  the  technology  to  implement  the  GH  ontology. 

•  Design  decisions  on  how  Generic  Hub  attributes  are  represented  in  the  ontology;  in 
other  words,  the  classes  and  slots  declared  in  the  GH  and  C2  ontologies  are  visible, 
but  classes  and  slots  of  underlying  ontologies  are  not. 

•  The  theories  underlying  methods  in  the  package  that  implement  procedural  abstrac¬ 
tions. 

The  secondary  secrets  are  the  algorithms  and  data  structures  used. 

Changes  in  this  package  are  likely  to  be  motivated  by  changes  to  the  Generic  Hub,  or  to  the 
representation  of  the  Generic  Hub  in  the  GH  ontology.  They  may  also  result  from  a  realiza¬ 
tion  of  how  to  improve  performance.  Extensions  to  this  package  result  from  observation  of 
repeated  code  dealing  with  the  GH  ontology,  or  from  realization  of  how  the  introduction  of  a 
procedural  abstraction  could  clarify  code. 

3. 5. 3. 5.  GPC 

The  gpc  (Geo-Position  Context)  package  contains  classes  that  encapsulate  the  specification  of 
a  location,  in  geocentric  coordinates.  The  package  provides: 

•  An  interface,  GeoPosition,  and  its  implementation,  GeoPositionlmpI,  that  specifies 
get/set  methods  for  defining  a  coordinate,  and  optionally  associating  the  name  of  a 
battlefield  object  with  that  coordinate. 

•  An  abstract  class,  AbstractGeoPositionContext,  that  partially  implements  a  Context, 
which  is  a  data  abstraction  useful  in  evaluating  FIPA  messages  (see  Section  3.6.1). 

The  primary  secrets  of  the  class  are: 

•  The  algorithms  and  data  structures  used  in  the  implementation  of  GeoPositionlmpI. 

•  The  algorithms  of  AbstractGeoPositionContext.  Note  that  AbstractGeoPositionContext  is 
abstract.  Its  data  structures  are  visible  to  any  class  that  extends  it,  but  not  outside  that 
class. 

3. 5. 3. 6.  Map 

The  map  package  contains  subpackages  and  classes  that  encapsulate  a  map  image  displayed 
in  the  Friendly  Organization  component  (see  Figure  5).  A  map  image  is  specified  in  an  XML 
document.  The  primary  secrets  of  the  package  are  the  DTD  describing  that  document,  as  well 
as  the  algorithms  and  data  structures  for  translating  a  map  specification  into  an  image,  and 
the  representation  of  a  map  image.  Changes  in  this  package  occur  in  response  to  changes  in 
the  information  associated  with  obtaining  a  map. 

3. 5. 3. 7.  Ontology 

The  ontology  package  contains: 
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•  A  set  of  interfaces  that  together  define  the  concept  of  an  ontology  for  the  purposes  of 
this  system. 

•  A  subpackage  impl,  each  subpackage  of  which  provides  a  single  implementation  of 
the  interfaces  in  the  ontology  package. 

The  interfaces  derive  from  Protege-2000’ s  interpretation  of  OKBC.  They  are  not  as  complete 
as  Protege-2000.  They  have  been  defined  to  suit  the  needs  of  the  IDA  prototype  simulation 
(for  example,  there  is  no  interface  for  a  facet).  They  could  be  expected  to  expand  as  the  pro¬ 
totype  simulation  grows  in  complexity. 

The  primary  secrets  of  this  package  are  the  classes  in  the  subpackages  of  impl  that  implement 
the  interfaces.  In  other  words,  the  view  of  an  ontology  in  this  system  is  provided  solely 
through  the  interfaces  of  ontology. 

A  subpackage  is  responsible  for  providing  access  to  instances  of  these  interfaces.  For  exam¬ 
ple,  impl  has  a  subpackage  protege.  The  only  class  of  protege  visible  outside  the  ontology  pack¬ 
age  is  ProtegeProject,  which  has  a  method  that,  given  the  URL  of  a  Protege-2000  project 
specification,  returns  an  instance  of  interface  KnowledgeBase  for  that  project.  The 
KnowledgeBase  interface  allows  access  to  all  classes,  slots,  and  instances  in  the  knowledge 
base. 

Changes  to  the  ontology  package  are  likely  to  occur  in  response  to  new  needs  for  access  to  an 
ontology. 

3. 5. 3. 8.  OSB 

The  osb  (Ontology-SQL  Binding)  package  contains  classes  that  bind  a  GH  ontology  to  an 
SQL  database.  The  SQL  database  is  specified  via  a  JDBC  (Java  Data  Base  Connectivity)  ob¬ 
ject.  The  binding  permits  a  knowledge  base  to  be  populated  from  a  GH-conformant  database, 
and  for  changes  to  a  knowledge  base  to  be  saved  into  a  GH-conformant  database  as  well.  The 
primary  secrets  of  this  package  are  the  algorithms  and  data  structures  used  to  implement  the 
binding.  Changes  in  this  package  are  likely  to  occur  in  response  to: 

•  The  use  of  an  RDBMS  that  supports  a  variant  of  SQL  not  currently  recognized. 

•  Need  for  performance  improvements. 

3. 5. 3. 9.  PA 

The  pa  (Procedural  Abstraction)  package  contains  classes  that  provide  procedural  abstrac¬ 
tions  that  are  independent  of  any  domain  defined  by  the  prototype  simulation.  These  include 
mathematics  (e.g.,  a  Poisson  distribution)  and  strings  (e.g.,  concatenate  a  list  of  strings).  The 
primary  secrets  of  this  package  are  the  algorithms  and  data  structures  used  to  implement  the 
abstractions.  Changes  in  this  package  are  likely  to  occur  in  response  to: 

•  Use  of  more  sophisticated  modeling  constructs  for  behavior 

•  Extensions  in  the  design  of  agents  that  require  additional  functionality 

3.5.3.10.  SQL 

The  sql  package  contains  classes  that  encapsulate  software  design  decisions  based  upon  pre¬ 
ferred  techniques  to  access  a  RDBMS  via  Java’s  java.sql  package.  Use  of  these  classes  is  not 
mandated  but  may  improve  clarity.  The  primary  secrets  of  this  package  are  the  algorithms 
and  data  structures  used  to  implement  the  classes.  Changes  in  this  package  result  from  a  de¬ 
sire  to  improve  performance. 
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3.5.4.  Software  Generation  Package 

The  Software  Generation  package  encapsulates  packages  that  assist  in  code  generation.  The 
primary  secrets  of  this  package  are  decisions  on  the  most  effective  way  to  specify  certain  as¬ 
pects  of  functionality  in  non-native  languages.  The  secondary  secrets  are  the  algorithms  and 
data  structures  used  in,  and  generated  by,  these  code  generation  packages.  Changes  to  the 
Software  Generation  module  are  motivated  by  new  ideas  on  how  to  represent  behavior  and 
functionality. 

3.5.4. 1.  XML  DTD  Translation 

The  XML  DTD  Translation  package  encapsulates  the  translation  between  a  DTD  and  a  set  of 
Java  classes.  It  hides  the  details  of  marshalling  and  unmarshalling  XML  documents.  Each 
DTD  element  is  translated  into  both  an  interface  and  a  class. 

The  primary  secrets  of  this  package  are: 

•  The  algorithms  and  data  structures  used  to  translate  a  DTD  into  Java. 

•  The  classes  into  which  an  element  is  translated  (i.e.,  only  the  interface  should  be  con¬ 
sidered  visible  outside  the  package),  except  for  the  class  that  unmarshals  an  XML 
document  based  on  the  root  element. 

The  IDA  prototype  simulation  uses  Zeus  to  implement  this  package. 

3. 5. 4. 2.  LL(l)  Translation  5 

The  LL(1)  Translation  package  encapsulates  the  specification  of  a  language  as  an  LL(1) 
grammar,  as  well  as  the  translation  of  an  LL(1)  grammar  into  Java.  The  primary  secrets  of 
this  package  are  the  properties  of  an  LL(1)  parser-generator.  The  secondary  secrets  are  the 
algorithms  used  for  translating  LL(1)  grammars  into  Java.  Changes  in  this  package  are  likely 
to  be  motivated  by  the  desire  for  increased  power  in  manipulating  an  LL(1)  language. 

The  prototype  uses  Sun  Microsystems ’s  javacc  parser-generator  to  implement  this  package. 

3.6.  Detailed  Discussion  of  Selected  Packages  and  Classes 

This  section  gives  an  in-depth  discussion  of  selected  elements  of  the  prototype  simulation.  It 
covers  important  design  and  implementation  decisions.  The  underlying  issues  are  likely  to 
arise  in  net-centric  systems.  This  section  is  intended  to  help  designers  understand  trade-offs. 

3.6.1.  The  SLO  Package 

SL  and  its  subsets  are  the  preferred  FIPA  languages  for  communicating  most  semantics. 
FIPA-OS  provides  minimal  support  for  SL,  however.  FIPA-OS  contains  an  SL  parser,  but  the 
output  of  the  parser  has  proven  difficult  to  use  [Duncan  2003],  FIPA-OS  also  contains  an 
SFO  parser,  but  that  parser  only  verifies  that  a  string  conforms  to  SLO  syntax;  it  does  not  gen¬ 
erate  a  parse  tree  that  an  application  can  analyze.  Example  FIPA-OS  applications  included  in 
the  distribution  use  ad  hoc  parsers.  Comments  in  FIPA-OS  documentation  mention  the  need 
for  improved  SF  support. 

In  anticipation  of  complex  and  disparate  messages,  the  IDA  prototype  simulation  implements 
a  subsystem  to  parse,  manipulate,  and  de-parse  SFO  strings.  The  package  is  an  exploration  of 


5  LL(k)  parsers  process  input  from  Left  to  right,  and  construct  a  Leftmost  derivation  of  the  sentence.  The 
number  of  tokens  it  uses  to  look  ahead  is  given  by  the  parameter  k. 
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how  an  agent-based  application  can  effectively  utilize  messages  whose  content  is  expressed 
using  SLO. 

The  package,  sd.FIPA.slO,  has  two  major  classes: 

1.  Class  SLO,  which  contains  nested  classes  that  implement  SLO  concepts. 

2.  Class  SLOParser,  a  parser-generator  that  translates  strings  into  instances  of  classes  in 
SLO. 

The  following  sections  describe  each  class. 

3.6.1. 1.  Class  SLO 

The  SLO  class  encapsulates  SLO  concepts.  A  concept  is  one  of  the  following: 

•  A  non-tenninal  in  the  SLO  grammar,  which  is  encapsulated  by  a  nested  class.  Most  of 
the  concepts  encapsulated  in  SLO  are  non-terminals.  An  important  purpose  of  SLO  is  to 
represent  parse  trees  for  the  SLO  language.  These  parse  trees  are  built  by  class 
SLOParser  and  used  by  agents. 

•  An  approach  to  manipulating  an  SLO  expression,  which  is  encapsulated  by  either  an 
interface  or  a  procedural  abstraction. 

Terminals  are  represented  as  the  Java  primitive  types  Integer,  Float,  and  String. 

3. 6. 1.1.1.  Encapsula  tion  of  Non  -Terminals 

Class  SLO  contains  a  nested  class  for  most  SLO  non-terminals  (some  exceptions  are  discussed 
below).  These  classes  have  get/set  methods  to  access  the  content  of  a  production.  For  exam¬ 
ple,  the  root  production  of  SLO  is: 

Content  =  “(“  ContentExpression+  “)”. 

Class  SLO  contains  nested  class  Content,  whose  signature  is  as  follows: 

public  static  class  Content  { 

public  Content(ContentExpression  ce); 
public  Content(List  contentExpressions); 
public  void  add(ContentExpression  ce); 
public  List  getContentExpressions(); 

} 

The  nested  classes  do  not  have  remove()  methods,  as  these  methods  are  not  needed  to  con¬ 
struct  parse  trees. 

Not  all  non-terminals  appear  in  class  SLO.  The  parse  tree  can  be  simplified  by  collapsing  SLO 
productions  that  have  a  single  expansion.  Consider  the  SLO  productions: 

Parameter  =  ParameterName  ParameterValue. 

ParameterName  =  String. 

ParameterValue  =Term. 

Class  SLO  has  nested  classes  Parameter,  Stmg  (the  abbreviated  name  avoids  confusion  with 
Java’s  built-in  class  String),  and  Term,  but  no  nested  class  ParameterName  or  ParameterValue. 
Instead,  it  provides  methods  in  class  Parameter  to  access  the  name  and  value: 

public  static  class  Parameter  { 

public  Parameter  (String  name,  Term  value); 
public  String  getNameQ; 
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public  Term  getValueQ; 


} 

Note  also  the  substitution  of  String  for  Stmg,  possible  for  the  same  reason.  Collapsing  produc¬ 
tions  simplifies  the  implementations  of  both  SLO  and  classes  that  import  it. 

If  an  SLO  production  has  multiple  right-hand  side  expansions,  the  non-terminal  on  the  left- 
hand  side  is  an  abstract  class,  and  SLO  contains  a  concrete  class  for  each  expansion;  these 
concrete  classes  extend  the  abstract  class.  This  approach  expresses  the  concept  a  non¬ 
terminal  encapsulates  while  accommodating  the  necessary  variations  of  the  expansions.  For 
example,  the  SLO  production: 

ContentExpression  =  ActionExpression 
|  Proposition. 

maps  to  the  following  classes  in  SLO: 

public  static  abstract  class  ContentExpression 
extends  BaseSLOSymbol  { ... } 
public  static  class  ActionExpressionContentExpression 
extends  ContentExpression  { ... } 
public  static  class  PropositionContentExpression 
extends  ContentExpression  { ... } 

The  chain  of  abstract  classes  continues  for  as  long  as  necessary.  The  SLO  productions: 

Term  =  Constant  | .... 

Constant  =  NumericalConstant 

|  String 
j  DateTime. 

NumericalConstant  =  Integer 
|  Float. 

are  encapsulated  by  the  nested  SLO  classes  shown  in  Figure  27  (italicized  names  denote  ab¬ 
stract  classes). 

The  nested  classes  that  encapsulate  non-terminals  all  extend  class  BaseSLOSymbol,  an  abstract 
class  that  requires  its  descendents  to  include  some  convenience  methods.  Most  significantly, 
BaseSLOSymbol  ensures  that  any  invocation  of  toStringQ  will  yield  an  instance  of  class 
java.lang. String  that  is  a  valid  SLO  representation  of  the  instance.  This  makes  use  of 
SLO. Content  instances  as  the  content  object  of  FIPA-OS  messages  easy: 

SLO.Content  c  =  new  Content(); 
c.addContentExpression(confenf  expression)] 

ACL  message  =  new  ACL(); 
message. setContentObject(c.toString()); 

3. 6. 1. 1.2.  Evaluating  Content 

When  an  agent  receives  an  SLO  message,  it  must  parse  and  evaluate  that  message.  The  fol¬ 
lowing  is  a  discussion  of  what  evaluation  means  and  how  the  IDA  prototype  simulation  im¬ 
plements  it. 

An  SLO  message  contains  content.  Content  is  composed  of  one  or  more  content  expressions. 
Each  content  expression  specifies  one  of  the  following: 
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1 .  A  fact  to  be  added  to  the  agent’s  knowledge  base.  This  fact  is  stated  as  a  proposition. 

2.  A  request  to  the  agent  to  state  whether  its  knowledge  base  contains,  or  can  be  used  to 
deduce,  a  fact.  This  fact  is  also  stated  as  a  proposition. 

3.  A  request  to  the  agent  to  perfonn  an  action.  The  action  is  stated  as  an  action  expres¬ 
sion,  which  has  the  forms: 

ActionExpression  =  “(“  “action”  Agent  Term 

where  the  Term  specifies  the  action  that  the  Agent  is  requested  to  perform.  An  SLO 
Term  can  be  an  arbitrary  expression,  but  as  an  action  expression  it  is  most  often  a 
function  that  the  sender  believes  the  receiver  understands.  For  example,  the  Tasks 
agent  of  the  Friendly  Organization  requests  the  SimState  agent  to  perform  the  sensing 
function  (Table  1). 

A  study  of  these  items  shows  that  an  agent  cannot  evaluate  content  expressions  in  isolation 
from  its  knowledge  base.  In  fact,  something  more  than  a  knowledge  base  is  necessary,  be¬ 
cause  of  the  SLO  FunctionalTerm  production: 

FunctionalTerm  =  “(“  FunctionSymbol  Term*  “)” 

|  “(“  FunctionSymbol  Parameter* 

The  FunctionSymbol  is  a  string.  SLO  establishes  no  requirement  that  it  be  part  of  the  knowl¬ 
edge  base;  that  is,  a  FunctionSymbol  is  not  necessarily  a  class  or  slot.  Evaluating  a  content  ex¬ 
pression,  then,  requires  that  permissible  functions  be  predefined. 

Several  messages  send  by  agents  of  the  prototype  use  functional  terms.  The  most  pervasive 
function  has  the  form: 

(position  latitude  lat  :longitude  Ion ) 

The  position  function,  when  evaluated,  yields  a  value  that  is  equivalent  to  an  instance  of  the 
AbsolutePoint  class  in  the  GH  ontology. 

Evaluating  a  context  expression  can  require  even  more  information  than  knowledge  base  and 
functions.  How  an  agent  handles  a  context  expression  that  is  a  proposition  depends  on  the 
communicative  act  associated  with  the  message.  The  interpretation  of: 

(has-location  obj-ltem-name  (position  latitude  lat  dongitude  /on)) 

depends  entirely  on  whether  it  is  associated  with  a  message  whose  communicative  act  is 
Inform  (item  1)  or  Query-lf  (item  2). 


Figure  27.  SLO  Class  Hierarchy  for  Constants 
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These  considerations  have  led  to  the  design  for  content  evaluation  that  will  now  be  presented. 
This  design  is  especially  suited  to  SLO,  and  probably  to  SL1.  It  is  not  so  well  suited  to  SL2  or 
SL. 

SLO  classes  that  encapsulate  non-tenninals  have  a  method  whose  signature  has  the  form: 

public  Object  evaluate(Context  context)  throws  EvaluationException; 

(Sometimes  the  method  returns  a  Boolean  or  a  List.)  SLO. Context  is  an  interface.  A  knowledge 
base  implementation  that  wishes  to  allow  evaluation  of  SLO  context  should  implement  the 
SLO. Context  interface. 

A  context  is  intended  to  be  more  general  than  a  knowledge  base.  A  knowledge  base  is  one 
type  of  context,  but  others  are  possible.  This  design  approach  derives  from  the  need  to  allow 
functions,  as  discussed  above.  It  also  accounts  for  the  fact  that  a  full  knowledge  base  can  be 
overkill.  The  agents  in  the  IDA  prototype  simulation  send  messages  that  do  not  require  the 
full  expressiveness  of  the  GH  ontology.  Constructing  a  “pseudo-ontology”  that  handles  just 
the  necessary  concepts  is  often  simpler.  Section  3. 5. 3. 5  presents  more  information  on 
pseudo-ontologies. 

The  SLO. Context  interface  has  the  following  signature: 
public  interface  Context  { 

public  Boolean  evaluateResult(Object  term,  Object  equivalentTerm) 
throws  EvaluationException; 
public  Boolean  truth()  throws  EvaluationException; 
public  String[]  getFunctionParams(String  functionName); 

} 

The  evaluateResult()  method  must  handle  evaluation  of  a  Result  atomic  formula,  which  has 
the  form: 

AtomicFormula  =  “(“  “result”  Term  Term  “)” 

and  means  that  the  sending  agent  believes  the  second  tenn  to  be  the  result  of  evaluating  the 
first  term.  This  atomic  formula  is  usually  sent  in  response  to  a  query  or  an  action  request,  and 
the  receiving  agent  will  want  to  implement  evaluateResultQ  to  assert  the  fact  of  equivalentTerm 
in  its  knowledge  base.  For  example,  the  SimState  agent  sends  a  result  to  a  Friendly  Organiza¬ 
tion  in  response  to  a  sensing  request.  The  second  term  is  a  set  of  (object  name,  position) 
pairs.  The  Friendly  Organization  will  want  to  record  these  object  names  as  being  detected  at 
the  specified  locations. 

The  truth ()  method  must  implement  a  proposition  whose  value  is  one  of  the  literals  “true”  or 
“false”.  These  literals,  though  valid  in  SLO,  have  little  use;  they  are  carryovers  from  more 
complete  SL  subsets.  FIPA  does  not  specify  the  effect  of  asserting  “false”.  Presumably  it 
could  wipe  a  knowledge  base  clean,  whereas  “true”  would  have  no  effect. 

The  getFunctionParams()  method  is  part  of  a  larger  paradigm  for  implementing  functions, 
proposition  symbols,  and  predicates.  All  are  handled  using  dynamic  evaluation.  Suppose  a 
message  contains  the  positionQ  function  given  above.  The  class  that  implements  SLO. Context 
must: 

•  Define  a  function  with  the  following  signature: 

public  Object  position(Float  latitude,  Float  longitude); 

•  Define  getFunctionParamsQ  to  return: 
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(StringO)  { “latitude”,  “longitude” } 

when  invoked  with  “position”  as  its  argument. 

Now  consider  what  happens  when  evaluating  the  SLO  term: 

(position  latitude  45.3  :longitude  40.0) 

The  IDA  prototype  simulation  will  parse  this  string  into  an  instance  of  SLO.FunctionalTerm. 
When  the  evaluate()  method  is  invoked  on  that  instance,  it  will  search  its  SLO. Context  argu¬ 
ment  for  a  method  named  position  with  two  arguments  that  are  both  floating-point  values.  On 
finding  the  list  of  all  such  methods,  evaluate()  will  invoke  the  first,6  passing  it  the  values  45.3 
and  40.0,  in  that  order.  The  evaluate()  method  does  not  use  the  value  the  positionQ  method  re¬ 
turns;  bear  in  mind  that  this  value  is  part  of  some  larger  context  defined  by  the  SLO  content 
expression  containing  the  position  function  invocation.  The  evaluate()  method  only  passes  on 
the  value  as  a  parameter  to  the  next  stage  of  the  contextual  evaluation. 

This  dynamic  function  evaluation  approach  is  used  to  handle  predicates  as  well.  If  an  SLO 
message  contains  the  atomic  formula: 

(has-location  “3rd  Armor  Rec  Coy”  (position  latitude  45.3  :longitude  40.0)) 
then  the  evaluate()  method  that  handles  the  instance  parsed  from  this  string  will  look  for  a 
function  in  the  context  with  the  signature: 

public  Boolean  hasLocation(String  name,  GeoPosition  position) 

and  invoke  it  with  the  two  terms  of  the  predicate. 

Three  points  deserve  mention.  First,  it  must  be  noted  that  the  predicate  name  has-location  is 
translated  into  a  Java  method  name.  SLO  allows  function  names  to  be  arbitrary  strings.  This 
won’t  do  for  Java  identifiers.  Some  mapping  must  be  introduced. 

Second,  the  hasLocation()  method  takes  a  string  and  a  GeoPosition  (see  Section  3.6.5)  as  argu¬ 
ments.  That  the  first  argument  is  a  string  is  obvious  from  the  left  term  of  the  SLO  atomic 
formula.  The  type  of  the  second  argument  happens  to  come  from  knowledge  of  the  imple¬ 
mentation  of  the  position()  method. 

Third,  the  hasLocation()  method  returns  a  Boolean  value  because  a  predicate  is  a  proposition, 
and  FIPA  propositions  are  either  true  or  false.  FIPA  does  not  provide  much  detail  on  the  se¬ 
mantics  of  evaluation.  The  effect  of  a  false  proposition  is  unclear. 

There  are  other  ways  to  implement  support  for  predicates.  A  predicate  is  analogous  to  a  slot 
in  an  ontology,  so  the  SLO. Context  interface  might  have  been  defined  with  methods  such  as 
the  following: 

public  Boolean  assertPredicate(String  name,  SLO.Term  terms); 
public  Boolean  verifyPredicate(String  name,  SLO.Term  terms); 

(The  first  form  is  for  Inform  communicative  acts,  the  second  for  Query-lf  acts.)  A  class  imple¬ 
menting  SLO. Context  could  then  map  the  name  to  a  slot.  For  a  knowledge  base  with  many 
slots,  this  would  be  considerably  easier  than  defining  a  separate  method  for  each  predicate 
(i.e.,  for  each  slot). 

Finally,  the  getFunctionParams()  method  is  necessary  because  there  are  two  forms  of  function 
terms: 


6  The  IDA  prototype  simulation  arbitrarily  evaluates  the  first  method  found.  A  more  realistic  approach  for  a 
production  system  would  be  to  throw  an  exception. 
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FunctionalTerm  =  “(“  FunctionSymbol  Term*  “)” 

|  “(“  FunctionSymbol  Parameter* 

The  examples  have  all  used  the  second  form,  in  which  parameters  are  named.  FIPA  discour¬ 
ages  but  does  not  forbid  use  of  the  first  fonn,  with  its  unnamed  parameters: 

(position  45.3  40.0) 

The  algorithm  that  matches  methods  to  functions  works  with  parameter  names,  so  an 
SLO. Context  must  be  able  to  detennine  the  name  of  each  parameter.  The  getFunctionParams() 
method  supplies  these  names.  Its  return  value  is  an  array  of  strings,  each  of  which  is  the 
name  of  a  parameter.  The  order  of  the  names  in  the  array  determines  the  assignment  of 
names  to  values  in  the  SLO  expression. 

3.6.I.2.  Class  SLOParser 

Class  SLOParser  converts  an  SLO  expression  into  an  instance  of  a  nested  class  in  SLO.  It  is 
usually  used  to  parse  content  expressed  in  SLO  through  the  static  parseContent()  method: 
SLO.Content  c; 

c  =  SLOParser.parseContent(  acl.getContentObject().toString() ); 

Class  SLOParser  is  implemented  using  Sun’s  javacc  parser  generator.  Javacc  simplifies  the 
construction  of  top-down  parsers  by  allowing  them  to  be  expressed  as  grammars.  For  exam¬ 
ple,  the  code  for  recognizing  the  production 

Content  =  “(“  ContentExpression+  “)”. 

is: 

SLO.Content  Content(): 

{  II  Declare  variables  needed  to  accumulate  ContentExpression  instances. 
SLO.ContentExpression  contentExpr; 

List  elements  =  new  LinkedList(); 

} 

{  II  The  following  derives  directly  from  the  grammar. 

<Lparen>  ( contentExpr  =  ContentExpression()  { elements.add(contentExpr); } )+  <Rparen> 

{ 

try  { 

return  new  SLO.Content(elements);  II  Construct  and  return  the  instance. 

}  catch  ( SLO.InvalidContentException  e )  { 

throw  new  ParseException(e.getMessage());  II  Oops. 

} 

} 

} 

The  grammar  in  SLOParser  follows  the  SLO  grammar  very  closely.  There  are  a  few  excep¬ 
tions: 

1.  The  SLO  production  for  an  Agent  (i.e.,  the  first  operand  of  an  Action  Expression)  is  a 
Term: 

Agent  =  Term. 

A  term  is  a  constant,  set,  sequence,  functional  tenn,  or  action  expression. 

The  FIPA-00070  specification  places  other  restrictions  on  the  syntax  of  an  Agent.  It 
must  have  the  form: 
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“(“  “agent-identifier”  “:name”  word  [  “:addresses”  URLSequence  ] 

[  “:resolvers”  AgentldentifierSequence  ] 

( UserDefinedParameter  Expression  )* 

The  parser  accepts  a  Term  by  default,  but  can  be  made  to  accept  only  agents  that  con¬ 
form  to  FIPA-00070. 

2.  FIPA’s  definition  of  a  double-quoted  string  is  extremely  liberal;  the  ending  double 
quote  is  optional.  This  isn’t  easy  to  recognize  using  javacc,  so  SLOParser  requires 
matching  quotes. 

3.6. 1.3.  Canonical  Code  for  Handling  INFORM  Messages 

The  following  fragment  shows  the  code  an  agent  uses  to  handle  a  message  with  the  INFORM 
communicative  act,  assuming  the  class  ContextClass  implements  the  Context  interface.  Real 
code  would  have  more  sophisticated  error  handling. 

public  void  handlelnform(Conversation  conv)  { 

ACL  acl  =  conv.getACL(conv.getLatestMessagelndex()); 
if  ( !  acl.getLanguage().equals(SLOParser.getLanguage()) )  { 
sendNotUnderstood(acl);  II  The  language  isn’t  SLO. 

return; 

} 

SLO.Content  content; 
try  { 

content  =  SLOParser.parseContent((String)acl.getContentObject()); 

}  catch  ( ParseException  e )  { 

sendNotUnderstood(acl);  II  The  content  is  syntactically  incorrect, 

return; 

} 

if  ( !  acl.getOntology().equals(ContextClass.getName()) )  { 

sendNotUnderstood(acl);  II  The  ontology  isn’t  what’s  expected, 

return; 

} 

SLO.Context  context  =  new  ContextClass(acl,  this); 
try  { 

content.evaluate(context);  II  Here’s  the  evaluation. 

}  catch  ( SLO.EvaluationException  e )  { 

sendNotUnderstood(acl);  II  Evaluation  failed. 

} 

} 

Note  that  the  ContextClass  constructor  takes  the  ACL  as  an  argument.  This  is  usually  neces¬ 
sary  because,  as  discussed  in  Section  3.6.1  above,  interpretation  of  SLO  depends  on  the 
communicative  act  associated  with  the  ACL. 

The  constructor  also  takes  the  task  instance  as  a  parameter.  Experience  with  the  IDA  proto¬ 
type  simulation  has  shown  that  having  the  ContextClass  invoke  callback  methods  in  its  parent 
is  a  useful  design  paradigm. 


B-52 


3.6.2.  The  Ontology  Package 

The  IDA  prototype  simulation  is  based  on  the  GH  ontology.  This  ontology  provides  the  data 
model.  The  rules  for  component  behavior  trace  to  the  GH  ontology,  either  directly  or  indi¬ 
rectly. 

The  GH  ontology  is  implemented  in  Protege-2000.  Protege-2000  is  one  of  many  tools  for 
creating  and  editing  knowledge  bases.  There  is  a  distinct  possibility  of  using  another  tool, 
perhaps  to  improve  perfonnance,  or  to  gain  access  to  new  functionality. 

Therefore,  the  prototype  hides  the  use  of  Protege-2000.  The  only  package  that  is  aware  of  its 
use  is  the  gh5ontology  package  (Section  3.6.3).  This  package  must  know  because: 

•  It  is  responsible  for  loading  the  knowledge  base,  which  requires  knowledge  of  the 
tool  to  perform  the  loading. 

•  It  has  expectations  of  the  capabilities  of  the  knowledge  base.  It  is  aware  that  the  GH 
ontology  supports  inferencing  in  Algernon  and  constraint  checking  in  PAL. 

The  rest  of  the  IDA  prototype  simulation  has  no  knowledge  that  Protege-2000  is  used.  In¬ 
stead,  the  IDA  prototype  components  access  a  knowledge  base  through  the  ontology  package. 
This  package  contains  a  set  of  interfaces  that  standardize  the  model  of  a  knowledge  base.  The 
interfaces  are  drawn  from  Protege-2000 ’s  package  edu.stanford.smi. protege. model  package. 
This  simplifies  implementation.  It  also  means  that  interfaces  in  the  ontology  package  follow 
OKBC,  giving  them  some  authority  as  a  useful  model. 

The  interfaces  are: 

1.  KnowlegeBase,  which  defines  operations  for  accessing  and  deleting  frames.  Each  in¬ 
stance  of  KnowledgeBase  represents  a  single  knowledge  base. 

2.  Frame,  which  denotes  a  single  frame  within  a  knowledge  base.  The  operations  provide 
for  accessing  own  slots. 

3.  Instance,  which  denotes  a  frame  that  is  an  instance. 

4.  CIs,  which  denotes  an  Instance  that  is  a  class  within  a  knowledge  base.  Its  operations 
access  superclasses  and  subclasses,  and  allow  the  creation  of  an  Instance. 

5.  Slot,  which  denotes  an  Instance  specialized  to  hold  values  of  a  specific  type.  Its  opera¬ 
tions  query  the  types  of  values  allowed. 

The  methods  in  these  interfaces  are  derived  almost  directly  from  Protege-2000.  Not  all  Pro¬ 
tege-2000  methods  have  been  included.  The  IDA  prototype  simulation  assumes  that  agents 
will  use  existing  ontologies,  not  construct  them;  therefore,  it  omits  methods  such  as  those  that 
add  classes  or  add  template  slots  to  classes. 

The  ontology  package  includes  two  other  interfaces: 

6.  ValidatableCIs,  an  extension  of  CIs  denoting  a  class  that  may  have  associated  validation 
rules.  It  has  a  single  method,  validate(),  that  when  invoked  is  expected  to  apply  any 
class-specific  validation  rules  in  the  knowledge  base.  The  meaning  of  a  validation 
rule  is  left  up  to  the  class  that  implements  the  interface. 

7.  ATKnowledgeBase,  an  extension  of  KnowledgeBase  denoting  a  knowledge  base  for 
which  “ask”  and  “tell”  queries  may  be  posed.  (An  “ask”  query  requests  the  knowl¬ 
edge  base  to  supply  all  instances  that  satisfy  the  query.  A  “tell”  query  requests  the 
knowledge  base  to  store  some  fact.) 
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These  two  interfaces  are  intended  to  support  PAL  and  Algernon,  respectively,  while  hiding 
the  validation  and  query  systems  a  knowledge  base  uses.  The  interfaces  are  experimental  and 
should  undergo  revision  based  on  experience  gained  from  other  knowledge  base  editors. 

The  ontology  package  has  a  subpackage  named  impl.  This  package  in  turn  has  subpackages, 
each  of  which  represents  an  implementation  of  the  interfaces  in  ontology  with  respect  to  a  par¬ 
ticular  knowledge  base  tool.  The  prototype  currently  implements  only  one  such  subpackage: 
protege,  which  implements  the  interfaces  for  Protege-2000.  Classes  in  the  protege  package 
implement  interfaces  in  ontology;  their  names  are  the  name  of  an  interface  suffixed  with  Impl. 
Clslmpl  implements  ValidatableCIs  and  KnowledgeBaselmpI  implements  ATKnowledgeBase,  re¬ 
flecting  the  validation  and  inferencing  capabilities  available  in  Protege-2000. 

The  classes  in  the  protege  package  are  wrappers  around  the  corresponding  Protege-2000 
class.  (Protege-2000  also  uses  the  interface/class  distinction,  preferring  that  applications  refer 
to  the  interfaces.  Extending  Protege-2000  classes  is,  therefore,  not  an  option.)  Each  class  has 
a  field  containing  the  underlying  Protege-2000  frame.  Methods  refer  to  that  frame  to  obtain 
results. 

The  classes  do  not  have  public  constructors.  An  application  may  create  a  frame  or  knowledge 
base  only  through  specific  methods;  this  ensures  that  a  knowledge  base  is  aware  of  all  of  its 
frames.  The  protege  package  contains  a  class  named  ProtegeProject  with  a  single  constructor: 

public  ProtegeProject(String  kbURL); 

and  a  single  method: 

public  KnowledgeBase  getKnowledgeBase(); 

The  ProtegeProject  class  is  a  wrapper  around  the  Protege-2000  class  Project.  It  is  used  only  to 
test  whether  the  project  opened  successfully  (the  constructor  throws  an  exception  on  failure) 
and  to  retrieve  the  associated  knowledge  base.  This  knowledge  base  is  an  instance  of 
KnowledgeBaselmpI,  i.e.,  it  implements  the  KnowledgeBase  interface.  The  constructor  creates 
this  instance  using  the  non-public  constructor  of  KnowledgeBaselmpI. 

3.6.3.  The  GH  ontology  Package 

The  ontology  package  hides  the  implementation  of  knowledge  base  technology.  A  GH  ontol¬ 
ogy  has  additional  infonnation  that  can,  and  should,  be  encapsulated.  This  information  in¬ 
cludes: 

1.  The  representation  of  own  slot  values.  An  agent  may  be  expected  to  know  the  ele¬ 
ments  of  the  GH  ontology  (class  names,  template  slot  names).  It  may  also  be  expected 
to  know  the  underlying  domain  of  a  slot,  as  taken  from  the  corresponding  attribute  in 
the  Generic  Hub  (integer,  real,  string).  However,  the  representation  of  own  slot  values 
is  subject  to  change  in  the  GH  ontology;  future  versions  may  not  use  the  Type  ontol¬ 
ogy,  for  example. 

2.  Procedural  abstractions  of  rules  for  accessing  GH  concepts.  For  example,  agents  of¬ 
ten  need  to  know  if  one  organization  commands  another.  The  rules  for  determining 
command  hierarchy  stem  from  Generic  Hub  coded  domains  that  may  be  subject  to 
extension.  Furthermore,  the  rules  can  be  implemented  several  ways  (Java,  Algernon, 
etc.).  They  should  be  consolidated  to  simplify  agent  maintenance  in  the  event  of 
change. 

The  gh5ontology  package  encapsulates  these  and  other  concepts.  Its  most  important  class  is 
GH5KB.  The  constructor  of  this  class  takes  as  a  parameter  a  KnowledgeBase  instance;  this  in- 
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stance  is  expected  to  be  a  GH  ontology  (if  it  isn’t,  its  use  will  soon  cause  exceptions).  The 
instance  may  then  be  used  to: 

•  Get  and  delete  frames,  as  prescribed  by  the  KnowledgeBase  interface. 

•  Get  and  set  slot  values  in  what  seems  the  most  natural  and  direct  way.  Consider  the 
following  fragment: 

GH5KB  kb  =  new  GH5KB(ProtegeProject(g/t-onfo/ogy-L/RL).getKnowledgeBase()); 

CIs  materielCIs  =  kb.getCls(“Materiel”); 

Collection  allMateriel  =  materielCls.getlnstances(); 

for  ( Iterator  miter  =  allMateriel.  iterator();  mlter.hasNext(); )  { 

Instance  materiel  =  (lnstance)mlter.next(); 

II  Here  are  some  methods  defined  in  GH5KB. 

String  name  =  kb.getStringSlot(materiel,  “name”); 

String  bodyColor  =  kb.getCodeSlot(materiel,  “bodyColourCode”); 

System. out.println(name  +  “  has  colour  “  +  bodyColor); 

} 

Methods  getStringSlotQ  and  getCodeSlot()  hide  the  details  of  how  the  GH  ontology 
represents  a  string  and  a  coded  domain. 

•  Retrieve  an  Instance  denoting  a  battlefield  object  based  on  its  name  and  class: 

Instance  org  =  kb.getBattlefieldObject(kb.getCls(“Unit”),  “Panzerbataillon  433”); 

•  Retrieve  all  battlefield  objects,  which  agents  use  to  search  for  instances  conforming  to 
some  property. 

•  Calculate  the  speed  of  a  battlefield  object  based  on  observations  of  its  position. 

•  Determine  command  properties  of  an  organization. 

These  and  other  methods  encapsulate  business  rules  for  the  GH  ontology. 

The  gh5ontology  package  contains  the  following  additional  classes: 

•  Class  DateTime  converts  between  GH  data  model  representations  of  dates  and  times 
and  Java’s  java.util. Calendar  instances. 

•  Class  NumericExpression  encapsulates  the  Numeric-Expression  ontology.  It  hides  how 
this  ontology  uses  slots  to  represent  numeric  expressions.  It  also  contains  an  evaluate() 
method  that,  given  an  Instance  whose  class  is  Numeric-Expression,  returns  the 
java.lang. Number  resulting  from  the  evaluation  of  the  instance. 

•  Classes  ReportingData,  RDComparator,  and  RDEComparator  support  comparing  a  collec¬ 
tion  of  ReportingData  instances,  or  alternately  a  collection  of  instances  that  have  asso¬ 
ciated  ReportingData.  The  comparison  is  based  on  either  the  date  and  time  a 
ReportingData  instance  was  created,  or  the  effective  date  and  time  specified  for  the  in¬ 
stance.  The  methods  can: 

•  Compare  two  instances,  returning  -1,  0,  or  1  depending  on  whether  one  in¬ 
stance  is  less  than,  equal  to,  or  greater  than  the  other  (the  usual  Java  paradigm 
specified  by  the  java.lang. Comparable  interface). 

•  Sort  a  list  of  instances. 

•  Retrieve  the  most  recent  instance  from  a  collection  of  instances. 
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3.6.4.  The  Ontology-SQL  Binding  Package 

The  Generic  Hub  was  designed  with  the  expectation  that  it  would  be  implemented  as  a  rela¬ 
tional  database  schema.  The  prototype  can  create  a  knowledge  base  from  a  Generic  Hub  data 
set  accessed  via  an  SQL  RDBMS.  The  IDA  prototype  simulation  can  also  save  changes  to  a 
knowledge  base  to  the  data  set  used  to  create  that  knowledge  base.  This  functionality  is  im¬ 
plemented  in  the  osb  (Ontology-SQL  Binding)  package. 

The  osb  package  contains  functionality  that  is  specific  to  linking  a  Generic  Hub  data  set  to  a 
GH  knowledge  base.  The  IDA  prototype  simulation  does  not  claim  to  encapsulate  general 
purpose  functionality  for  translating  between  an  arbitrary  knowledge  base  and  an  arbitrary 
database  schema.  An  architecture  for  such  functionality  would  be  useful,  but  time  constraints 
did  not  permit  a  study  of  the  issues. 

The  osb  package  contains  a  class  OntologySQLBinding  that  implements  the  majority  of  the 
package’s  functionality.  It  offers  the  following  methods: 

1 .  A  constructor  that  creates  a  binding.  Its  signature  is: 

public  OntologySQLBinding(  SchemaKBMap  map, 

GH5KB  kb, 

Connection  dbConnection); 

Note  that  the  binding  involves  a  GH5KB  instance,  not  an  arbitrary  ontology.  It  is  ex¬ 
pected  to  be  empty  when  the  constructor  is  invoked.  The  other  two  parameters  are: 

a)  A  SchemaKBMap  specification  of  how  Generic  Hub  elements  map  to  classes 
and  slots  of  the  GH  ontology.  This  map  is  taken  from  an  XML  document 
whose  DTD  is  translated  into  Java  classes  using  Zeus.  Its  DTD  is  discussed  in 
Section  3. 6.4. 2. 

b)  A  java.sql.Connection  to  a  DBMS  via  JDBC. 

2.  A  method  to  populate  the  knowledge  base  given  to  the  constructor  using  data  ob¬ 
tained  through  the  connection,  translating  data  according  to  the  map. 

3.  Methods  to  update  the  knowledge  base  with  all  data  entered  after  a  certain  time,  typi¬ 
cally  the  later  of  the  last  update  or  the  last  save.  Each  Friendly  Organization  compo¬ 
nent  has  a  different  knowledge  base;  these  methods  ensure  that,  if  two  components 
share  the  same  data  set,  each  component’s  knowledge  base  reflects  knowledge  ob¬ 
tained  by  the  other. 

4.  Methods  to  save  instances  into  the  underlying  data  set.  A  Friendly  Organization  com¬ 
ponent’s  inferences  sometimes  generate  new  facts  in  the  knowledge  base.  These 
methods  perform  the  reverse  of  the  update  methods. 

3.6.4. 1.  Saving  and  Updating  Instances 

The  save  and  update  operations  require  some  consideration.  The  desired  approach  to  saving 
would  be  to  implement  a  method  whose  signature  is  simply: 
public  void  save(); 

and  whose  effect  is  to  save  all  changes  since  the  last  save  or  update,  whichever  is  more  re¬ 
cent. 

This,  however,  is  difficult  to  implement  for  two  reasons.  The  first  is  determining  which  in¬ 
stances  in  the  knowledge  base  have  been  saved  or  modified  since  the  last  save  operation. 
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Marking  algorithms  for  this  sort  of  problem  are  well  known,  but  not  especially  easy  to  im¬ 
plement. 

The  second  reason  is  that  instances  cannot  be  saved  in  an  arbitrary  order.  The  standard  SQL 
script  to  create  a  Generic  Hub  data  set  places  integrity  constraints  on  tables.  Subtype  tables 
require  a  corresponding  row  in  their  supertype  tables.  A  foreign  key  in  the  child  table  re¬ 
quires  the  existence  of  a  corresponding  row  in  the  linked  parent  table. 

The  IDA  prototype  simulation  circumvents  these  problems  by  having  OntologySQLBinding  re¬ 
quire  that  instances  to  save  be  explicitly  specified,  and  that  they  be  specified  in  an  order  con¬ 
sistent  with  integrity  constraints.  An  example  signature  of  a  method  in  osb  to  save  instances 
is: 

public  void  savelnstances(List  instances); 

This  solution  violates  infonnation  hiding  principles,  because  it  relies  on  packages  outside  of 
osb  knowing  of  integrity  constraints  imposed  by  the  RDBMS.  It  is  not  recommended  for  a 
production  system. 

The  issue  with  an  update  operation  is  that  it  potentially  requires  comparing  an  entire  Generic 
Hub  data  set  against  a  knowledge  base.  This  would  be  unacceptably  slow.  One  solution 
would  be  to  extend  the  Generic  Hub  schema  with  an  additional  table  (or  tables)  that  record 
change.  Locally  extending  a  standard,  however,  may  negatively  impact  data  interoperability 
and  should  be  avoided  whenever  other  approaches  can  suffice. 

The  osb  package  instead  makes  an  assumption:  All  changes  to  a  Generic  Hub  data  set  will 
involve  an  instance  of  REPORTING-DATA.  This  assumption  is  justifiable,  because  Generic  Hub 
data  comes  from  observations,  and  REPORTING-DATA  records  information  about  an  observation. 
Moreover,  each  REPORTING-DATA  row  contains  infonnation  on  the  date  and  time  it  was  entered. 
The  date  and  time  are  used  to  retrieve  all  data  entered  after  a  specified  moment. 

Each  REPORTING-DATA  row  is  associated  with  a  row  from  an  associative  table.  This  row  is  pre¬ 
sumed  to  be  new.  The  update  method  essentially  performs  a  transitive  closure,  following  for¬ 
eign  keys  to  look  for  new  or  modified  rows. 

Assuming  that  all  updates  involve  REPORTING-DATA  has  some  flaws.  Almost,  but  not  all,  tables 
in  the  Generic  Hub  are  consistent  with  this  assumption.  One  counterexample  is  OBJECT-TYPE- 
CAPABILITY-NORM.  If  Generic  Hub  data  set  were  populated  with  new  object  types  and  their  ca¬ 
pabilities,  the  update  methods  would  not  detect  the  change.  Another  involves  actions:  neither 
ACTION-FUNCTIONAL-ASSOCIATION  nor  ACTION-TEMPORAL-ASSOCATION  has  associated  REPORTING- 
DATA.  REPORTING-DATA  is  associated  with  dynamic  data,  not  static  data  of  the  sort  that  is  likely 
to  be  used  in  the  initial  population  of  a  Generic  Hub  data  set.  The  mutability  of  tables  con¬ 
taining  such  data  is  not  known.  One  solution  would  be  to  restart  decision  support  systems 
when  these  tables  are  changed,  an  approach  that  may  or  may  not  be  practical.  The  problem 
needs  more  study. 

3. 6. 4. 2.  The  Schema  Map 

To  create  knowledge  base  instances  from  rows  of  a  table,  and  conversely  to  save  instances  as 
new  rows  of  a  table,  requires  some  knowledge  of  the  relationship  between  the  GH  ontology 
and  the  Generic  Hub  schema.  This  knowledge  is  encapsulated  by  an  XML  document,  the 
format  of  which  is  defined  by  the  DTD  shown  in  Figure  28.  This  document  essentially  reca¬ 
pitulates  all  Generic  Hub  physical  elements  (tables  and  columns,  not  entities  and  attributes), 
noting  relationships  to  the  GH  ontology  for  each  element.  For  each  Generic  Hub  table,  the 
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<!ELEMENT  schema-KB-map  (table-map+)> 


<!ELEMENT  table-map  (primary-key,  organic-column*,  relationship*^ 


<!ATTLIST  table-map 

maps-to-cls  CDATA 
table-name  CDATA 
discrim-value  CDATA 
discrim-column  CDATA 


#REQUIRED 

#REQUIRED 

IMPLIED 

#IMPLIED> 


<!ELEMENT  primary-key  (key-column+)> 

<!ELEMENT  key-column  EMPTY> 

<!ATTLIST  key-column 

name  CDATA  #REQUIRED 

type  (integer|float|string)  #REQUIRED 
slot-name  CDATA  #IMPLIED> 


<!ELEMENT  organic-column  EMPTY> 
<!ATTLIST  organic-column 

name  CDATA 

maps-to-slot  CDATA 
slot-type  (int|float|string) 

match  (false|true) 

trim  (falsejtrue) 


#REQUIRED 

#REQUIRED 

IMPLIED 

"false" 

"false"> 


<!ELEMENT  relationship  (key-column+)> 

<!ATTLIST  relationship 

slot-name  CDATA  #REQUIRED 

associated-cls-name  CDATA  #REQUIRED> 


Figure  28.  Schema  Map  DTD 


document  gives  the  table’s  name  and  notes  the  class  to  which  it  maps.  It  also  categorizes  the 
table’s  columns:  primary  keys,  organic  columns,  and  relationships.  A  primary  key  is  speci¬ 
fied  simply  as  a  column  name  and  a  type  (one  of  integer,  float,  or  string).  An  organic  column 
is  specified  as  a  name,  a  type  (one  of  int,  float,  or  string),  and  the  name  of  a  single-cardinality 
slot  to  which  it  maps;  this  slot  must  be  a  template  slot  of  the  class  to  which  the  table  maps. 
See  Figure  29,  which  shows  how  the  NETWRK  SERVICE  table  maps  to  the  NetworkService  class. 

An  organic  column  has  two  other  attributes.  The  trim  attribute  applies  to  columns  whose  type 
is  string,  and  indicates  that  values  should  be  trimmed  prior  to  being  used  as  the  values  of  in¬ 
stances.  The  match  attribute,  which  also  applies  to  string-typed  columns,  indicates  that  the 
value  must  match  an  existing  value  of  the  slot  type;  new  values  are  not  to  be  created.  The  trim 
and  match  attributes  together  denote  a  coded  domain.  During  initial  design  of  the  osb  pack¬ 
age,  it  seemed  probably  that  trim  would  be  used  without  match,  but  this  never  occurred. 

A  relationship  describes  a  table’s  foreign  keys.  The  relationship  is,  therefore,  associated  with 
the  child  table.  The  attributes  of  the  relationship  are  the  GH  ontology  slot  that  models  it  (the 
single  cardinality  slot  with  a  multiple  cardinality  inverse)  and  the  name  of  the  class  with  the 
multiple  cardinality  slot.  For  example,  the  relationships  for  table  NETWRK  SERVICE  describes 
that  class  Network  has  a  multiple-cardinality  slot  provides-NetworkService.  Note  also  that  the 
specification  of  the  primary  key  for  NETWRK_SERVICE  shows  that  column  netwrkjd  maps  to  slot 
netwrk_service-is-provided-by-Network.  This  is  the  inverse  of  slot  provides-NetworkService. 
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<table-map  table-name- 'NETWRK_SERVICE"  maps-to-cls- 'NetworkService"> 

<primary-key> 

<key-column  name="netwrk_id"  type- 'integer" 

slot-name="netwrk_service-is-provided-by-Network"  /> 

<key-column  name="netwrk_service_ix"  type="integer"  /> 

</primary-key> 

<organic-column  name="cat_code"  maps-to-slot- 'categoryCode" 
trim- 'true"  match- 'true"  /> 

<organic-column  name-'subcat_code"  maps-to-slot- 'subcategoryCode" 
trim- 'true"  match- 'true"  /> 

crelationship  slot-name="provides-NetworkService"  associated-cls-name="Network"> 
<key-column  name="netwrk_id"  type="integer"  /> 

</relationship> 

</table-map> 

Figure  29.  Schema  Map  Fragment 

The  DTD  contains  two  other  (related)  attributes  that  merit  discussion.  Databases  implement 
subtype  relationships  through  a  discriminator  attribute.  The  GH  ontology  only  partially  pre¬ 
serves  this  attribute.  All  discriminators  are  named  categoryCode;  unlike  the  logical  model  of 
the  Generic  Hub,  the  GH  ontology  makes  no  distinction  between  object-item-category-code  and 
organisation-category-code.  This  is  a  reasonable  design  decision,  because  the  GH  ontology  con¬ 
tains  type  operations  that  make  discriminators  in  superclasses  redundant.  However,  discrimi¬ 
nator  values  are  necessary  when  saving  instances.  When  the  prototype  saves  an  instance  of 
AbsolutePoint,  for  example,  it  must  save  rows  in  tables  ABS  POINT,  POINT,  and  LOC.  It  must  know 
to  set  the  value  of  the  cat_code  column  of  POINT  to  'ABS',  and  the  value  of  the  cat_code  column 
of 'LOC' to 'PT'. 

This  infonnation  is  encoded  in  the  discrim-value  and  discrim-column  attributes  of  the  table-map 
element.  The  discrim-value  attribute  is  the  value  to  which  the  discrim-column  attribute  of  the 
supertype  table  must  be  set.  For  example: 

<table-map  table-name- ’POINT"  maps-to-cls- 'Point"  discrim-value- ’PT"  discrim- 
column="cat_code"> 

<table-map  table-name- 'ABS_POINT"  maps-to-cls- 'AbsolutePoint"  discrim-value="ABS"> 

The  schema  map  focuses  on  how  tables  map  to  classes.  This  reflects  the  decision  to  imple¬ 
ment  database  load  operations  before  knowledge  base  save  operations. 

Finally,  the  tables  must  be  given  in  the  XML  document  such  that  supertypes  appear  before 
subtypes.  This  restriction  simplifies  parsing  and  processing. 

3.6.5.  The  GPC  Package:  A  Pseudo  Ontology 

Expressing  facts  about  the  GH  ontology  can  be  complex.  For  example,  the  description  of  a 
battlefield  object  o’s  current  reported  location  involves  a  sequence  of  relationships  involving 
Objectltem,  ObjectltemLocation,  ReportingDataAbsoluteTiming,  and  AbsolutePoint: 


Equation  1.  Set-Theoretic  Expression  for  Last  Reported  Location 

loc={  p  e  AbsolutePoint  | 

V  oil  e  ObjectltemLocation 
V  r  e  ReportingDataAbsoluteTiming 
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is-geometrically-defined-through(o,  oil) 
a  is-associated-with(oz7,  p) 
a  is-referenced-to(oz7,  r) 
a— i3  r'e  ReportingDataAbsoluteTiming 
((effcctivcDatc(r)  =  cffcctivcDatc(r)  a  (cffcctivcTime(r)  >  cffcctivcTimc(r)) 
v  effectiveDate(r  )  >  effectiveDate(r))  } 

The  problem  as  concerns  agent  development  is  not  the  complexity  of  this  expression.  Com¬ 
plexity  must  not  be  discounted,  for  it  increases  both  the  probability  of  errors  during  devel¬ 
opment  and  the  difficulty  developers  face  during  maintenance  of  comprehending  an  agent’s 
behavior.  Simplicity  is  always  desirable.  But  the  real  problem  is  implementing  functionality 
to  interpret  these  expressions. 

Set-theoretic  expression  interpreters  are  inherently  slow.  As  mentioned  on  p.  B-26,  many  ex¬ 
pressions  are  computationally  intractable.  Agent  designers  must  exercise  caution  when  con¬ 
sidering  what  facts  they  might  add  to  a  knowledge  base.  Asking  an  interference  engine  to 
evaluate  an  expression  such  as  the  above  will  strain  computational  resources. 

FIPA  recognizes  this  problem  and  addresses  it  through  its  subsets  of  SL.  These  subsets  are,  however,  lim¬ 
ited.  SLO  cannot  express 

Equation  1,  because  it  lacks  Boolean  operators.  SL1  cannot  either;  it  lacks  quantifiers.  SL2 
can  (though  not  quite  in  this  form;  it  does  not  allow  quantifiers  to  be  nested  inside  anything 
other  than  quantifiers).  Implementing  support  for  SL2  is  effort-intensive,  however. 

The  challenge  in  the  IDA  prototype,  then,  was  how  to  express  complex  facts.  Using  SL2  was 
deemed  infeasible  because  of  lack  of  resources  to  pursue  that  approach.  Its  use  also  remains 
unproved  in  production  systems. 

The  IDA  prototype  instead  introduces  the  concept  of  a  pseudo-ontology.  A  pseudo-ontology 
is  built  on  top  of  another  ontology,  rather  like  the  C2-Concepts  ontology  is  built  on  top  of  the 
GH  ontology.  A  pseudo-ontology’s  distinguishing  feature  is  that  it  defines  an  explicit  transla¬ 
tion  between  its  relationships  and  its  underlying  ontology.  This  translation  can  be  imple¬ 
mented  in  a  language  such  as  Java.  The  translation  can  include  knowledge  of  the  underlying 
ontology  and  therefore  can  be  far  more  efficient  than  an  SL  (or  SL2)  expression  evaluator. 
Agents  can  express  facts  in  SLO  or  SL1.  The  prototype  uses  SLO,  expressions  of  which  are 
always  computationally  tractable. 

Table  1  shows  some  pseudo-ontologies.  The  geo-position  ontology,  for  example,  concisely 
expresses  the  last  known  recorded  location  of  a  battlefield  object  as  an  absolute  point.  (The 
location  is  most  recent  because  the  ontology  defines  it  to  be  so). 

A  pseudo-ontology  contains  as  few  classes  and  slots  as  are  necessary  to  express  facts.  Typi¬ 
cally  only  one  or  two  classes,  and  not  many  more  slots,  are  needed.  Consider  the  following 
fact  in  the  geo-position  ontology,  expressed  in  SLO: 

((has-location  “Panzerbattalion  433”  (position  latitude  43.20  :longitude  -78.6))) 

This  fact  can  be  modeled  using  a  single  class:  Geo-Position,  with  template  slots  latitude, 
longitude,  and  name  (because  the  ontology  contains  a  single  class,  has-location  does  not  have  to 
be  modeled  explicitly).  When  an  agent  receives  the  above  fact,  it  translates  these  slots  into 
classes  in  the  GH  ontology.  The  IDA  prototype  currently  has  the  SimState  agent  send  geo- 
position  ontology  messages  to  the  Friendly  Organization  component,  which  assigns  the 
HumanlntelTask  to  receive  them.  The  HumanlntelTask: 
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•  Creates  an  instance  of  AbsolutePoint  using  the  given  latitude  and  longitude. 

•  Finds  the  instance  of  Objectltem  with  the  given  name. 

•  Creates  the  necessary  additional  class  instances: 

•  ObjectltemLocation,  which  it  relates  to  the  Objectltem  and  AbsolutePoint  in¬ 
stances. 

•  ReportingDataAbsoluteTiming,  for  which  it  sets  the  timing  characteristics  from 
the  moment  when  it  received  the  message. 

A  message  using  a  pseudo-ontology  requires  support  for  both  the  sender  and  the  receivers. 
Both  can  benefit  from  encapsulation  of  shared  concepts.  However,  each  has  different  needs 
from  the  ontology.  The  sender  is  concerned  with  packaging  content.  The  receiver  is  con¬ 
cerned  with  understanding  it. 

The  prototype  includes  a  package  named  gpc.  This  package  implements: 

•  An  interface  GeoPosition  and  its  implementation  class  GeoPositionlmpl.  This  class  pro¬ 
vides  get/set  methods  for  name,  latitude,  and  longitude,  and  represents  a  relationship 
of  an  object  item  name  to  a  geodetic  position. 

•  An  abstract  class  AbstractGeoPositionContext.  This  class  implements  the  SLO. Context  in¬ 
terface,  and  provides: 

•  A  specification  of  a  function  named  position.  The  domain  of  this  function  is  an 
ordered  pair  of  floating-point  values  denoting  latitude  and  longitude,  respec¬ 
tively.  The  range  is  GeoPosition. 

•  The  FIPA-OS  ACL  instance  that  contained  the  fact.  This  instance  is  main¬ 
tained  as  a  protected  field  of  the  class. 

Section  3. 6. 1.1. 2  discussed  how  a  class  that  implements  SLO. Context  need  not  be  a  knowledge 
base.  AbstractGeoPositionContext  is  such  a  class.  Pseudo-ontologies  in  the  IDA  prototype  do 
not  need  the  full  power  of  an  ontology. 

Both  the  SimState  and  the  Friendly  Organization  components  extend  class 
AbstractGeoPositionContext.  (The  Enemy  Organization  component  does  not;  it  sends  messages 
that  use  the  position  function,  but  it  never  evaluates  them.)  The  SimState  component  defines  a 
GeoPositionContext  class  that  adds: 

•  An  implementation  of  the  has-location  predicate  that  records  the  location  of  the  indi¬ 
cated  object. 

•  An  implementation  of  the  sensing  action. 

The  Friendly  Organization  component,  which  requests  the  SimState  component  to  perform 
the  sensing  action,  receives  responses  of  the  form: 

((result 

(action  simstate-agent-name 
(sensing 

:center  (position  latitude  lat-1  :longitude  Ion-1) 

:northwest  (position  latitude  lat-2  :longitude  Ion-2))) 

(set  (position  latitude  lat  :longitude  Ion  :name  n)  ...))) 

The  action  term  identifies  the  message  sent.  The  set  term  contains  the  results.  The 
GeoPositionContext  class  of  the  Friendly  Organization  component  adds  an  evaluateResult() 
method  that  iterates  through  each  element  of  the  set.  GeoPositionContext  lets  the  instantiating 
instance  determine  what  to  do  with  each  element.  In  the  Friendly  Organization  component, 
class  HumanlntelTask  instantiates  GeoPositionContext,  and  for  each  element  it  compares  the  lo- 
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cation  with  the  previously  known  location  (if  any),  using  this  information  to  detennine  if  the 
sensed  object  is  moving  and  posing  a  threat. 

3.6.6.  The  SQL  Package 

Package  java.sql,  a  standard  component  of  the  Java  Runtime  Environment,  has  classes  and 
methods  for  accessing  a  data  set  using  SQL.  These  classes  provide  most  of  the  functionality 
needed  for  database  access.  However,  the  IDA  prototype  contains  some  common  code  that 
has  been  encapsulated  in  a  package  named  sql  as  procedural  abstractions: 

•  SQL  has  a  standard  for  quoting  strings  that  differs  from  Java’s.  In  SQL,  embedded 
single  quotes  must  be  escaped  by  doubling  them.  The  sql  package  provides  methods 
quote()  and  unquote(). 

•  Of  the  many  data  types  SQL  supports,  the  Generic  Hub  uses  only  three:  strings,  inte¬ 
gers,  and  floating-point  values.  Encapsulating  this  knowledge  ensures  that  all  other 
packages  must  confonn  to  the  Generic  Hub’s  typing  structure.  The  sql  package  pro¬ 
vides  public  fields  that  define  the  range  of  permissible  types. 

•  New  instances  require  unique  keys.  The  sql  package  contains  methods  to  support  gen¬ 
erating  keys.  (The  IDA  prototype  makes  specialized  assumptions  about  key  genera¬ 
tion.) 

•  A  single  knowledge  base  save  operation  can  executes  multiple  update  and  insert  que¬ 
ries.  To  help  ensure  database  integrity,  the  sql  package  provides  a  method  to  handle 
these  queries  as  a  single  transaction. 

•  Not  all  SQL  RDBMSs  implement  transactions  (Microsoft  Access  is  one  example). 
The  sql  package  encapsulates  transaction  management  to  hide  the  lack  of  availability 
of  transactions. 

3.6.7.  The  FIPA  Package 

Apart  from  SLO,  there  are  many  opportunities  for  encapsulating  design  decisions  regarding 
the  use  of  FIPA  standards  and  FIPA-OS. 

3.6. 7.1.  Searching  for  Agents 

Locating  other  agents  is  a  fundamental  agent  action.  Moreover,  an  agent  is  seldom  satisfied 
to  perform  a  single  search.  It  must  know  what  agents  are  available  at  the  time  it  needs  other 
agents  to  perform  a  task. 

The  FIPA  package  includes  two  generic  classes  for  finding  agents.  They  are: 

1.  Class  AgentSearchTask,  which  is  an  extension  of  the  FIPA-OS  Task  class.  It  is  instan¬ 
tiated  with  a  string  describing  the  type  of  agent  for  which  to  search.  On  completion,  it 
invokes  method: 

public  void  doneAgentSearchTask(Object  results) 

in  its  parent  task.  The  results  parameter  is  an  array,  each  element  of  which  describes 
an  agent  with  the  service  type  specified  on  instantiation. 

2.  Class  PeriodicAgentSearchTask,  which  performs  an  agent  search  repeatedly.  Its  con¬ 
structor  takes  a  service  type  and  an  integer: 

public  PeriodAgentSearchTask(String  serviceType,  int  requerylnterval) 

The  effect  is  to  start  a  search  for  the  specified  service  type.  The  search  will  repeat 
every  requerylnterval  seconds  until  explicitly  stopped  by  the  parent. 

Class  PeriodicAgentSearchTask  is  an  abstract  class.  Its  subclass  must  declare  a  method: 
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public  void  utilize(Collection  agents,  boolean  changed) 

This  method  is  invoked  each  time  a  search  completes.  The  agents  parameter  gives  the 
agents  that  match  the  service  type.  The  changed  parameter  specifies  whether  this  col¬ 
lection  is  identical  to  that  given  when  utilize()  was  last  invoked.  (Knowing  of  no 
change  can  save  an  agent  from  having  to  check  whether  infonnation  needs  to  be  re¬ 
sent.) 

The  FIPA  package  also  contains  two  classes  for  finding  specific  types  of  agents: 

1.  Class  SimStateAgentSearchTask,  which  performs  a  search  for  a  SimState  agent.  Be¬ 
cause  each  execution  of  the  IDA  prototype  simulation  must  have  exactly  one  Sim- 
State  component,  this  task  searches  until  it  finds  the  component,  then  ends.  It  uses  the 
AgentSearchTask  class  to  perfonn  the  actual  search. 

2.  Class  AbstractFindOverviewAgentsTask,  which  searches  for  all  Overview  agents.  It  ex¬ 
tends  PeriodicAgentSearchTask  by  providing  the  service  type  for  which  to  search  and 
the  search  interval.  It  is  an  abstract  class  for  which  a  subclass  must  still  implement 
utilize(). 

For  example,  the  SimState  component  implements  its  search  for  Overview  agents  in  its 
IdleT ask,  as  follows: 

public  class  IdleTask  extends  Task  { 

private  Collection  _overviewAgents  =  new  LinkedList(); 

/**  Callback  method  invoked  automatically  by  FIPA-OS  when  the  task  starts.  */ 
protected  void  startTask()  { 

II  Begin  a  continuous  search  for  OverviewAgents. 
newTask(  new  FindOverviewAgentsTask() ); 

} 

public  class  FindOverviewAgentsTask  extends  AbstractFindOverviewAgentsTask  { 
public  void  utilize(Collection  OverviewAgents,  boolean  changed)  { 
if  ( changed )  { 

synchronized  ( _overviewAgents )  { 

_overviewAgents  =  new  LinkedList(overviewAgents); 

} 

} 

} 

} 

Other  methods  in  IdleTask  may  assume  that  _overview Agents  contains  the  most  recent  search 
results.  Note  the  synchronization,  which  is  generally  necessary  in  applications  using  FIPA- 
OS.  Messages  may  be  received  at  any  time,  and  may  overlap  with  the  invocation  of  UtilizeQ. 

3.6. 7.2.  The  C4IAgent  Class 

The  FIPA-OS  paradigms  for  actions  performed  on  start-up  and  shutdown  vary  little  between 
agents: 

•  All  agents  extend  FIPA-OS  classes  FIPAOSAgent  and  must  invoke  its  constructor  with 
parameters  that,  except  for  the  agent  name,  don’t  change. 
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•  Agents  register  with  the  AMS  and  then  the  DF.  This  involves  catching  some  excep¬ 
tions  that  are  noted  in  a  log  file  but  otherwise  ignored. 

•  On  shutdown,  agents  deregister  with  the  DF  and  then  the  AMS.  As  with  registration, 
exceptions  entail  no  response  other  than  noting  their  presence. 

The  prototype  encapsulates  agent  start-up  and  shutdown  actions  by  creating  abstract  class 
C4IAgent.  This  class  removes  about  50  SLOC  from  every  agent  in  the  prototype. 

3. 6. 7. 3.  The  FIPAACL  Class 

FIPA  specification  00070  describes  the  string  representation  of  an  ACL  message.  The  proto¬ 
type  includes  a  class  FIPAACL  whose  role  is  to  encapsulate  knowledge  of  that  representation. 
Currently  it  contains  two  methods:  quote()  and  unquote().  Callers  invoke  the  quote()  method  as 
part  of  creating  an  ACL  message  to  ensure  that  message  content  is  properly  formatted.  Call¬ 
ers  invoke  the  unquote()  method  on  receiving  an  ACL  message  to  extract  content. 

3. 6. 7. 4.  The  Notification  Package 

Several  agents  need  to  inform  other  agents  of  some  fact.  This  action  occurs  sufficiently  often 
that  it  pays  to  encapsulate  it.  The  notification  package  contains  two  classes: 

1.  Class  InformAgentTask,  which  informs  a  single  agent.  That  is,  it  creates  an  ACL  mes¬ 
sage  using  specified  content,  language,  ontology,  sets  the  message’s  communicative 
act  to  INFORM,  and  sends  that  message  to  a  specified  recipient.  When  an  instance  of 
InformAgentTask  exits,  FIPA-OS  will  invoke  the  donelnformAgentTask()  method  in  the 
parent. 

2.  Class  InformAgentTask,  which  is  identical  to  InformAgent,  except  that  it  informs  a  set  of 
agents  rather  than  a  single  agent. 

Both  classes  use  the  No-Protocol  protocol,  meaning  that  the  sending  agent  expects  no  response 
from  receivers.  Use  of  No-Protocol  is  probably  unrealistic  in  a  production  environment.  More 
study  of  the  abstraction  is  needed  to  determine  how  sending  messages  with  other  protocols 
could  be  encapsulated. 

3.6.8.  Java  Properties 

Java  encourages  the  specification  of  runtime  configuration  parameters  through  properties. 
Properties  are  accessible  -  and  settable  -  through  class  java.lang. System.  Properties  standard¬ 
ize  how  a  Java  application  can  query  its  environment. 

The  IDA  prototype  simulation  relies  on  properties  (as  do  the  systems  the  IDA  prototype 
uses).  The  IDA  prototype  makes  use  of  the  properties  shown  in  table  2.  All  properties  are 
prefixed  with  “ida”  to  distinguish  them  from  any  other  properties  that  might  be  needed. 


Table  2.  Runtime  Properties  Used  by  the  Prototype 


Property 

Domain 

Purpose 

ida. app. interactive 

0  or  1 

If  0,  the  application  is  not  running  interactively.  It  will 
have  no  user  interface,  and  therefore  no  human  controller. 

ida.config.file 

Any  URL 

The  URL  of  a  configuration  file  for  the  loader.  See  Sec¬ 
tion  2.6. 

ida.datasource 

db 

The  source  from  which  Generic  Hub  data  is  to  be  ob¬ 
tained.  Currently  this  property’s  value  must  be  the  string 
“db”. 

ida.db.url 

Any  URL 

The  URL  of  the  RDBMS  that  will  be  used  to  access  a 

B-64 


Generic  Hub  data  set.  Its  format  is  RDBMS  vendor  spe¬ 
cific. 

ida.db. username 

Any  string 

A  user  name  to  access  the  RDBMS,  if  one  is  required. 

ida.db. password 

Any  string 

A  password  for  the  user  name,  if  one  is  required. 

ida.db. sqldriver 

Fully  qualified  Java 
class  name. 

The  name  of  the  Java  class  that  implements  JDBC  for  the 
RDBMS. 

ida. ontology. uri 

Any  URL 

The  URL  of  the  GH  ontology.  It  must  be  a  valid  Protege- 
2000  project  name. 

ida.schemamap.url 

Any  URL 

The  URL  of  a  schema  map  file.  See  Section  3.6.4. 

Some  of  these  properties  (e.g.,  ida.db. username)  are  optional.  Moreover,  some  can  be  speci¬ 
fied  in  a  loader  configuration.  The  loader  will  set  properties  as  specified  so  that  each  system 
component  started  by  the  loader  finds  its  properties  as  expected. 


3.6.9.  Protocols 

FIPA  specifies  that  agents  shall  conduct  conversations  according  to  an  interaction  protocol. 
An  interaction  protocol  (protocol  for  short)  defines  valid  sequences  of  communicative  acts. 
An  agent  that  adheres  to  a  protocol  can  infer  the  state  of  the  conversation  (that  is,  what  acts 
have  occurred  so  far)  and  the  possible  responses  to  a  message  (that  is,  what  acts  can  occur 
next). 

FIPA  specifies  several  protocols,  and  also  permits  agents  to  define  their  own.  FIPA-OS  sup¬ 
ports  the  predefined  FIPA  protocols  (fipa-request,  fipa-query,  no-protocol,  etc.).  Agents  should 
use  predefined  protocols  whenever  possible,  as  the  sending  agent  is  assuming  the  receiving 
agent  understands  its  protocol. 

Many  FIPA  protocols  have  been  developed  to  support  negotiation  (e.g.,  fipa-brokering,  fipa- 
auction-english,  fipa-propose).  Such  protocols  are  not  suited  to  the  decision  support  functional¬ 
ity  implemented  by  the  IDA  prototype  simulation.  Its  agents  expect  'yes'  or  'no'  answers,  not 
barter  and  compromise. 

The  IDA  prototype  simulation  uses  two  protocols.  Mostly  its  agents  send  messages  using 
protocol  no-protocol.  Under  this  protocol,  agents  send  a  message  but  expect  no  response  (see 
Section  3. 1.3.3).  These  messages  use  the  Inform  communicative  act. 

The  IDA  prototype  simulation  also  introduces  its  own  protocol,  which  is  named  request-reply. 
Figure  30  shows  the  protocol  as  a  sequence  diagram.  The  sender  (the  HumanlntelTask  of  a 
Friendly  Organization)  requests  the  receiver  (the  IdleT ask  of  the  SimState  agent)  to  provide 
information;  the  SimState  agent  either  provides  that  information,  or  indicates  failure  (failure 


Figure  30.  The  Request-Reply  Protocol 
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occurs  if  the  Friendly  Organization  sends  a  malfonned  request). 

This  protocol  is  a  simplification  of  the  fipa-request  protocol.  It  avoids  that  protocol’s  exten¬ 
sive  error  handling.  The  request-reply  protocol,  while  appropriate  for  a  prototype,  is  probably 
not  suited  to  a  production  system. 

It’s  also  worth  noting  that  more  advanced  decision  support  systems  could  make  use  of  barter¬ 
ing  protocols.  An  organization’s  decision  support  application  might  send  a  request  for  mate¬ 
riel,  facilities,  and  personnel  in  support  of  its  current  task.  The  receiving  agents  would  bal¬ 
ance  the  request  against  current  supplies  and  objectives,  and  respond  accordingly. 
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Annex  C:  Friendly  Organization  Implementation 

This  annex  presents  the  implementation  of  the  Friendly  Organization  component  of  the  IDA 
prototype  simulation.  The  Friendly  Organization  component  exhibits  the  most  complex  be¬ 
havior  of  all  components.  It  also  makes  the  most  extensive  use  of  agents  and  ontologies. 

Annex  B  gives  a  high-level  view  of  the  Friendly  Organization  component’s  design.  This  an¬ 
nex  complements  Annex  B  with  detailed  design  and  implementation  information.  Annex  B 
breaks  components  down  into  packages.  This  annex  continues  with  classes  and  their  con¬ 
tents. 

1.  Package  and  Class  Structure 

Figure  1  recounts  the  packages  of  which  the  Friendly  Organization  component  consists,  and 
shows  the  outer  classes  in  each  package.  Behavior  related  to  a  friendly  organization  is  encap¬ 
sulated  within  the  friendlyorg  package.  The  direct  classes  of  friendlyorg  implement  a  decision 
support  application.  Subpackages  of  friendlyorg  implement  agent-specific  functionality.  Sub¬ 
packages  have  an  outer  class  named  IdleT ask  that  implements  the  root  task  of  the  FIPA-OS 
task  hierarchy.  A  FriendlyOrg  is  an  application,  not  an  agent,  so  it  has  no  IdleT  ask.  The  class 
Tasks,  however,  is  implemented  as  an  agent  (see  Annex  B,  Section  3.2.2)  and  has  an  inner 
class  IdleT  ask. 

Figure  1  illustrates  some  of  the  naming  conventions  used  for  classes: 


FriendlyOrgApp 
Friend  lyOrg 
FriendlyOrgGUI 


Tasks 

HumanlntelTask 

GeoPositionContext 


—  ThreatExaminationGUI 
— ThreatNotif  icationGU  I 
COAAnalysisGUI 


threat 


perception 

ThreatPerceptionAgent 


IdleTask  1 — ThreatPerception 

InformThreatResponseAgentsTask 


response 


ThreatResponseAgent  LCourseOf Action 


IdleTask 


A 


dbupdate 


DBUpdateAgent 
L  IdleTask 


FormulateDefend 
OrderThreatenedOrgToWithdraw 
OrderOtherOrgToSupport 
RequestPermissionToWithdraw 
SupportThreatenedOrg 


ThreatResponseNotification 

ThreatStmtContext 


Figure  1.  Friendly  Organization  Component  Package  and  Class  Structure 
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•  A  class  that  implements  a  “true”  FIPA-OS  agent  has  a  name  that  ends  with  Agent.  (A 
true  agent  performs  agent  operations,  as  opposed  to  a  class  implemented  as  an  agent 
to  make  use  of  functionality  provided  by  FIPA-OS.) 

•  A  class  that  encapsulates  a  graphical  user  interface  has  a  name  that  ends  with  GUI. 
Note  that  some  packages  have  several  GUIs.  Each  class  denotes  a  distinct  class  of 
window  presented  to  a  user. 

•  A  class  that  implements  a  FIPA-OS  Task  has  a  name  that  ends  with  Task. 

Note  that  the  response  package  shows  not  only  classes  but  class  hierarchy  relationships 
among  those  classes  concerned  with  expressing  a  course  of  action  that  a  friendly  organization 
might  adopt. 

2.  Documentation  Conventions 

The  code  for  the  prototype  is  documented  according  to  the  conventions  for  the  javadoc  tool. 
These  conventions  help  to  standardize  the  content  and  format  of  API  documentation.  See 
http://iava.sun.eom/i2se/l.4.2/docs/tooldocs/iavadoc/  for  more  information. 

Javadoc  translates  comments  of  the  form  /*  ...  */  into  input  to  an  HTML  interpreter.  These 
comments  often  contain  HTML  elements.  The  translated  version,  viewed  in  a  browser,  is 
generally  easier  to  comprehend.  The  HTML  versions  are  included  on  the  CD  that  accompa¬ 
nies  this  document. 

The  prototype  adds  one  non-standard  javadoc  tag:  “@todo”.  This  tag  indicates  an  aspect  of 
functionality  needed  in  a  production  system  but  beyond  the  scope  of  a  prototype. 
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3.  Classes  in  Package  FriendlyOrg 
3.1.  Class  FriendlyOrgApp 

The  FriendlyOrgApp  class  launches  a  Friendly  Organization  component.  It  consists  of  a  single  method,  main(),  which  as  per  Java  stan¬ 
dards  is  a  static  method  whose  sole  parameter  is  an  array  of  strings.  Fields  of  the  class  store  static  values  used  for  initialization  of  de¬ 
faults. 

package  ida.bh.cro.friendlyorg; 
import  java.io.InputStreamReader; 
import  java.io.BufferedReader; 

jit* 

*  The  <code>FriendlyOrgApp</code>  class  lets  a  <code>FriendlyOrg</code>  be  run  as  an  application.  Usage  is:<pre> 

java  FriendlyOrgApp  [-a  N]  [-E]  [-h]  [-s  N]  [-u  N]  org-name  map-spec</pre> 

*  The  flags  are  as  follows: 

*  <dl  compact> 

*  <dt><code>-a  N</code></dt> 

*  <dd>Set  the  interval  between  searches  for  threat  response  agents  to  <i>N</i>  seconds 

*  (default:  {@link  FriendlyOrg#DEFAULT_THREAT_RESPONSE_AGENT_SEARCH_INTERVAL})</dd> 

*  <dt><code>-e  F</code></dt> 

*  <dt><code>-E</code></dt> 

*  <dd>When  a  line  containing  <code>end</code>  is  received  on  <code>stdin</code>,  exit.  Intended  for  use  with  the  loader.</dd> 

*  <dt><code>-h</code></dt> 

*  <dd>Hide  the  user  interface,  i.e.,  make  the  GUI  invisible. </dd> 

*  <dt><code>-r  N</code></dt> 

*  <dd>Set  the  interval  between  ontology  refreshes  from  the  DBMS  to  <i>N</i>  seconds 

*  (default:  {@link  FriendlyOrg#DEFAULT_ONTOLOGY_REFRESH_INTERVAL}. 

*  <dt><code>-s  N</code></dt> 

*  <dd>Set  the  interval  between  searches  for  threats  to  <i>N</i>  seconds 

*  (default:  {@link  FriendlyOrg#DEFAULT_THREAT_SEARCH_INTERVAL}).</dd> 

*  <dt><code>-u  N</code></dt> 

*  <dd>Set  the  interval  between  searches  for  db  update  agents  to  <i>N</i>  seconds 

*  (default:  {@link  FriendlyOrg#DEFAULT_DB_UPDATE_AGENT_SEARCHJNTERVAL}).</dd> 

*  </dl> 

*  The  two  required  arguments  are: 

*  <dl  compact> 

*  <dt><code>org-name</code></dt> 
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*  <dd>The  name  of  the  organisation  this  application  is  to  model.  Must  be  the  name  of  an  organisation  in  the  ontology. </dd> 

*  <dt><code>map-spec</code></dt> 

*  <dd>The  URL  of  the  map  specification. </dd> 

*  </dl> 

**  j 

public  class  FriendlyOrgApp  { 

private  final  static  String  FLAGS[]  =  {"[-a  threat-response-agent-search-interval]", 

"[-E]", 

"-h", 

"[-r  ontology-refresh-interval]", 

"[-s  threat-search-interval]", 

"[-u  db-update-agent-search-interval]" }; 
private  final  static  String  ARGS[]  =  { "org-name",  "map-spec" }; 

private  static  String  usage; 
private  static  String  pgmName; 

static  { 

_pgmName  =  FriendlyOrgApp. class. getName(); 

_usage  =  "Usage:  java  "  +  _pgmName; 
int  i; 

for  ( i  =  0;  i  <  FLAGS. length;  i++  ) 

_usage  +=  " "  +  FLAGS[i]; 
for  ( i  =  0;  i  <  ARGS. length;  i++  ) 

_usage  +=  " "  +  ARGS[i]; 

} 

jit* 

*  Creates  a  friendly  organization  component.  The  parameters  are  described  above. 

*  @param  args  Parameters  of  the  component,  specified  as  strings. 

**  j 

public  static  void  main(String  args[  ])  { 

String  orgName; 

String  mapSpec; 

Integer  threatSearch Interval  =  new  lnteger(FriendlyOrg.DEFAULT_THREAT_SEARCH_INTERVAL); 

Integer  responseAgentSearchlnterval  =  new  lnteger(FriendlyOrg.DEFAULT_THREAT_RESPONSE_AGENT_SEARCH_INTERVAL); 
Integer  dbUpdateAgentSearch Interval  =  new  lnteger(FriendlyOrg.DEFAULT_DB_UPDATE_AGENT_SEARCH_INTERVAL); 

Integer  ontologyRefreshlnterval  =  new  lnteger(FriendlyOrg.DEFAULT_ONTOLOGY_REFRESH_INTERVAL); 
boolean  exitOnEndlnput  =  false; 
boolean  visible  =  true; 
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int  i  =  0; 

while  ( i  <  args. length  &&  args[i].substring(0,  1).equals("-") )  { 
if  (  args[i].equals("-help") )  { 

System. out.  println(_usage); 

System. exit(0); 

} 

if  ( i  ==  args. length  - 1  &&  !  (args[i].equals("-E")  ||  args[i].equals("-h")) )  { 

System. err.println(_pgmName  +  Missing  argument  to  V"  +  args[i]  +  "\"  flag."); 

System. err.  println(_usage); 

System. exit(1); 

} 

if  (  args[i].equals("-a") )  { 

try  { 

responseAgentSearchlnterval  =  lnteger.valueOf(args[i+1]); 

}  catch  (  NumberFormatException  e  )  { 

System. err.println(_pgmName  +  Invalid  response  agent  search  interval  V"  +  args[i+1]  + 

System. err.  println(_usage); 

System. exit(1); 

} 

i  +=  2; 

} 

else  if  (  args[i].equals("-h") )  { 
visible  =  false; 
i++; 

} 

else  if  (  args[i].equals("-E") )  { 
exitOnEndlnput  =  true; 
i++; 

} 

else  if  (  args[i].equals("-r") )  { 

try  { 

ontologyRefreshlnterval  =  lnteger.valueOf(args[i+1]); 

}  catch  (  NumberFormatException  e  )  { 

System. err.println(_pgmName  +  Invalid  ontology  refresh  interval  V"  +  args[i+1]  + 

System. err.  println(_usage); 

System. exit(1); 

} 

i  +=  2; 
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else  if  (  args[i].equals("-s") )  { 

try  { 

threatSearchlnterval  =  lnteger.valueOf(args[i+1]); 

}  catch  (  NumberFormatException  e  )  { 

System. err.println(_pgmName  +  Invalid  threat  search  interval  V"  +  args[i+1]  + 

System. err.  println(_usage); 

System. exit(1); 

} 

i  +=  2; 

} 

else  if  (  args[i].equals("-u") )  { 

try  { 

dbllpdateAgentSearchlnterval  =  lnteger.valueOf(args[i+1]); 

}  catch  (  NumberFormatException  e  )  { 

System. err.println(_pgmName  +  Invalid  db  update  agent  search  interval  V"  +  args[i+1]  + 
System. err.  println(_usage); 

System. exit(1); 

} 

i  +=  2; 

} 

else  { 

System. err.println(_pgmName  +  Unknown  flag  V"  +  args[i]  + 

System. err.  println(_usage); 

System. exit(1); 

} 

} 

if  ( i  !=  args. length  -  2  )  { 

System. err.println(_pgmName  +  Missing/extra  arguments."); 

System. err.  println(_usage); 

System. exit(1); 

} 

orgName  =  args[i++]; 
mapSpec  =  args[i]; 

FriendlyOrg  friendlyOrg; 

try  { 

friendlyOrg  =  new  FriendlyOrg( orgName, 

new  java.net.URL(mapSpec), 
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threatSearchlnterval, 
responseAgentSearchlnterval, 
dbllpdateAgentSearchlnterval, 
ontologyRefresh  Interval, 
new  Boolean(visible)); 

}  catch  (java. net. MalformedURLException  e  )  { 

System. err.println(_pgmName  +  Malformed  URL  V"  +  mapSpec  +  "  +  e.getMessage()); 

System. exit(1); 

}  catch  (  FriendlyOrg.UnknownOrgNameException  e  )  { 

System. err.println(_pgmName  +  V"  +  orgName  +  Unknown  organisation."); 

System. exit(1); 

return; 

}  catch  (  FriendlyOrg.InvalidMapSpecificationException  e  )  { 

System. err.println(_pgmName  +  V"  +  mapSpec  +  Invalid  map  specification: "  +  e.getMessage()); 

System. exit(1); 

return; 

} 

} 

} 

3.2.  Class  FriendlyOrg 

The  FriendlyOrg  class  is  the  decision  support  application  for  a  Friendly  Organization  component.  Its  salient  method  is  its  constructor, 
which  the  FriendlyOrgApp  class  invokes  to  instantiate  the  class  and  thereby  create  the  run-time  infrastructure  for  a  friendly  organization. 
Other  externally  visible  methods  are  callback  routines  invoked  from  classes  to  which  an  instance  of  FriendlyOrg  passes  itself.  The  most 
important  of  these  methods  is  update(),  invoked  as  part  of  the  model-view-controller  paradigm.  The  update()  method  responds  to  events 
from  Friendly  Organization  subcomponents.  These  components  are  generally  implemented  as  agents.  An  important  exception  is  the 
GUI  (see  Section  3.3),  which  sends  a  “shut-down”  signal  to  FriendlyOrg  when  the  user  wants  to  terminate  the  application. 

package  ida.bh.cro.friendlyorg; 

import  java. net. URL; 
import  java. util. HashMap; 
import  java. util. HashSet; 
import  java. util. Iterator; 
import  java. util. LinkedList; 
import  java. util. List; 
import  java. util. Observable; 
import  java. util. Set; 
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import  ida.sd.*; 

import  ida.sd. adt.OrganisationObserver; 

import  ida.sd. FIPA.C4IAgent; 

import  ida.sd.gh5ontology.*; 

import  ida.sd.gpc. GeoPosition; 

import  ida.sd. map. mapspec.MapSpec; 

import  ida.sd. map. mapspec.MapSpecUnmarshaller; 

import  ida.sd.ontology.*; 

import  ida.sd. ontology. impl. protege. ProtegeProject; 
import  ida.sd. osb.*; 
import  ida.sd. pa. StringPA; 

import  ida.bh.cro.friendlyorg.dbupdate.DBUpdateAgent; 
import  ida.bh.cro.friendlyorg. threat. perception. ThreatPerceptionAgent; 
import  ida.bh.cro.friendlyorg. threat. perception. ThreatPerception; 
import  ida.bh.cro.friendlyorg. threat. response.*; 

I** 

*  The  <code>FriendlyOrg</code>  class  implements  an  instance  of  a  friendly  organisation. 

*  Each  friendly  organisation  has  a  map  that  it  displays.  This  map  shows  the  organisation's  proximate  area,  its  location,  and  other  battlefield 

*  objects  in  the  area.  Knowledge  of  these  objects  is  dynamic,  based  on  communications  and  intelligence. 

*  <p>Each  friendly  organisation  is  in  contact  with  other  friendly  organisations  via  a  communication  network. 

*  It  senses  intelligence.  When  it  receives  intelligence,  it  broadcasts  that  intelligence  to  other  friendly  organisations,  and  updates  its  map. 

**  j 

public  class  FriendlyOrg 

implements  OrganisationObserver  { 

/**  Default  time,  in  seconds,  between  searches  of  the  ontology  for  threats.  */ 
public  final  static  int  DE F AU LT_T H REAT_S EARCH  I NTE RVAL 
/**  Default  time,  in  seconds,  between  searches  for  threat  response  agents.  */ 
public  final  static  int  DEFAULT  THREAT  RESPONSE  AGENT  SEARCHJNTERVAL 
/**  Default  time,  in  seconds,  between  searches  for  DBUpdateAgents.  */ 
public  final  static  int  D  E  F  AU  LTD  B_U  P  D  ATEAG  E  N  T_S  EARCHINTERVAL 
/**  Default  time,  in  seconds,  between  refreshes  of  the  ontology  from  the  DB.  */ 
public  final  static  int  DEFAULT  ONTOLOGY  REFRESH  INTERVAL 

/**  If  <code>FriendlyOrg</code>  receives  this  message,  it  terminates.  */ 
public  final  static  String  SHUTDOWN_MESSAGE  =  "shutdown"; 

/**  If  <code>FriendlyOrg</code>  receives  this  message,  it  asks  all  overview  agents  to  flash  its  location.  */ 
public  final  static  String  FLASH  MESSAGE  =  "flash"; 


=  50; 
=  50; 
=  50; 
=  60; 
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/**  The  user  interface  for  this  organisation.  7 
private  FriendlyOrgGUI  _gui; 

/**  The  friendly  organisation  {@link  Instance}  controlling  this  <code>FriendlyOrg</code>.  7 
private  Instance  _org; 

/**  The  name  of  the  organisation  controlling  this  <code>FriendlyOrg</code>.  7 
private  final  String  orgName; 

/**  A  list  of  the  agents  launched  by  this  application.  Needed  to  shut  them  down.  7 
private  List_agents  =  new  java. util. LinkedList(); 

/**  The  DB  update  agent,  which  is  responsible  for  (what  else?)  propagating  DB  updates.  7 
private  DBUpdateAgent  _dbllpdateAgent; 

/**  The  Tasks  agent,  which  performs  mundane  non-ontology  related  tasks.  7 
private  Tasks  tasksAgent; 

/**  True  if  this  application  was  invoked  from  the  command  line,  false  if  not.  7 
private  final  boolean  Jslnteractive; 

/**  True  if  this  instance  has  a  visible  GUI,  false  if  not.  7 
private  final  boolean  visible; 

/**  Names  of  organisations  perceived  to  be  a  threat.  7 
private  List_threats  =  new  LinkedList(); 

/**  The  {@link  ThreatPerceptionAgent}  launched  by  this  application.  7 
private  ThreatPerceptionAgent  _threatPerceptionAgent; 

/**  The  GH5  {@link  KnowledgeBase}  for  this  application.  7 

private  final  GH5KB  _gh5KB; 

/**  The  {@link  OntologySQLBinding}  for  this  application.  7 
private  final  OntologySQLBinding  _osb; 

/**  The  class  for  an  AbsolutePoint.  An  Objectltem  can  only  be  loaded  onto  the  map  if  its 

*  Location  is  an  AbsolutePoint  instance.  (Eventually  we'll  handle  other  Location  subclasses.)  7 
private  final  CIs  absolutePointCIs; 

jit* 

*  Constructs  a  <code>FriendlyOrg</code>  instance.  It  is  responsible  for: 

*  <ul> 

*  <li>Creating  an  instance  of  the  GH5  ontology. </li> 

*  <li>Populating  the  ontology  from  a  DBMS,  if  so  specified. </li> 

*  <li>Caching  battlefield  objects. </li> 

*  <li>Starting  agents: 

*  <ul> 

*  <li>A  {@link  ThreatPerceptionAgent}.</li> 
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*  <li>A  {@link  ThreatResponseAgent}.</li> 

*  <li>A  {@link  DBUpdateAgent},  if  a  DBMS  is  being  used.</li> 

*  <li>A  {@link  Tasks}  agent,  to  handle  incoming  messages. </li> 

*  </ul> 

*  </li> 

*  <li>Launching  the  GUI ,</li> 

*  </ul> 

*  @param  orgName  The  name  of  the  organisation  controlling  this  <code>FriendlyOrg</code>. 

*  @param  mapSpecURL  The  URL  of  the  map  specification. 

*  @param  threatSearchlnterval  The  interval,  in  seconds,  between  times  when 

*  threats  are  to  be  perceived.  If  null,  defaults  to 

*  {@link  #DEFAULT_THREAT_SEARCH_INTERVAL}. 

*  @param  threatResponseAgentSearchlnterval  The  interval,  in  seconds,  between  times 

*  when  searches  for  threat  response  agents  are  to  occur.  If  null,  defaults  to 

*  {@link  #DEFAULT_THREAT_RESPONSE_AGENT_SEARCHJNTERVAL}. 

*  @param  dbUpdateAgentSearchlnterval  The  interval,  in  seconds,  between  times 

*  when  searches  for  {@link  DBUpdateAgent}s  are  to  occur.  If  null,  defaults  to 

*  {@link  #DEFAULT_DB_UPDATE_AGENT_SEARCH_INTERVAL}. 

*  @param  ontologyRefreshlnterval  The  interval,  in  seconds,  between  times  when 

*  the  ontology  is  to  be  refreshed  from  the  DB.  If  null,  defaults 

*  to  {@link  #DEFAULT_ONTOLOGY_REFRESH_INTERVAL}. 

*  @param  visible  If  true,  show  a  GUI;  if  false,  keep  the  GUI  invisible.  A  value  of  false 

*  also  prevents  display  of  threat  responses.  If  null,  defaults  to  true. 

*/ 

public  FriendlyOrg(String  orgName, 

URL  mapSpecURL, 

Integer  threatSearchlnterval, 

Integer  threatResponseAgentSearchlnterval, 

Integer  dbUpdateAgentSearchlnterval, 

Integer  ontologyRefreshlnterval, 

Boolean  visible)  throws  InvalidMapSpecificationException,  UnknownOrgNameException  { 
_orgName  =  orgName; 

visible  =  (visible  —  null  ?  true  :  visible. booleanValue()); 

Jslnteractive  =  System.getProperty(ida. eh. Properties. interactiveApp,  "0").equals("1"); 

II  Open  the  ontology. 

try  { 

_gh5KB  =  GH5KB.openFromProperties(); 

}  catch  (  OntologyLoadException  e  )  { 
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System. err.  println(e.getMessage()); 
if  ( Jslnteractive  ) 

System. exit(1); 

return; 

} 

II  Load  data  into  the  knowledge  base,  if  so  specified. 

String  dataSource  =  System.getProperty(ida. eh. Properties. dataSource); 
if  (  dataSource  !=  null )  { 

if  (  dataSource. equalsfdb") )  { 

try  { 

_osb  =  BindingPA.getBindingllsingSystemProperties(_gh5KB); 

_osb.populateKBfromDB(); 

}  catch  (  BindingException  e  )  { 

System. err.println("Binding  exception: "  +  e.getMessage()); 

return; 

} 

} 

else  { 

System. err.println("Unknown  external  data  source  V"  +  dataSource  + 

return; 

} 

} 

else  { 

_osb  =  null; 

} 

_org  =  _gh5KB.getObjectltem(_orgName); 
if  ( _org  ==  null ) 

throw  new  UnknownOrgNameException(_orgName); 

CIs  orgCIs  =  _gh5KB.getCls("Organisation"); 

CIs  orgType  =  _org.getDirectType(); 

if  ( !  (orgType. equals(orgCls)  ||  orgType. hasSuperclass(orgCls)) ) 

throw  new  UnknownOrgNameException(_orgName  +  "  (a  "  +  orgType.getName()  +  ",  not  an  Organisation)"); 

II  Note  that  we  create  a  GUI  even  if  it  won't  be  visible.  We  need  the  GUI's  map  to  test  for  visible  threats. 

_gui  =  new  FriendlyOrgGUI(this,  orgName,  mapSpec(mapSpecURL)); 

//  Launch  the  agents. 

if  ( threatSearchlnterval  ==  null ) 
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threatSearchlnterval  =  new  lnteger(DEFAULT_THREAT_SEARCH_INTERVAL); 
if  ( threatResponseAgentSearchlnterval  ==  null ) 

threatResponseAgentSearchlnterval  =  new  lnteger(DEFAULT_THREAT_RESPONSE_AGENT_SEARCH_INTERVAL); 
_agents.add(_threatPerceptionAgent  =  new  ThreatPerceptionAgent(_gh5KB, 

"tp_"  +  _orgName, 
orgName, 

this, 

threatSearchlnterval, 
threatResponseAgentSearchlnterval)); 
_agents.add(new  ThreatResponseAgent(_gh5KB,  "tr_"  +  _orgName,  this)); 

if  ( _osb  !=  null )  { 

if  (  dbllpdateAgentSearchlnterval  ==  null ) 

dbllpdateAgentSearchlnterval  =  new  lnteger(DEFAULT_DB_UPDATE_AGENT_SEARCH_INTERVAL); 
_dbllpdateAgent  =  new  DBUpdateAgent("dbu_"  +  _orgName,  dbllpdateAgentSearchlnterval,  _osb); 
_osb.setDBUpdateAgent(_dbllpdateAgent); 

_agents.add(_dbllpdateAgent); 

if  (  ontologyRefresh Interval  ==  null ) 

ontologyRefreshlnterval  =  new  lnteger(DEFAULT_ONTOLOGY_REFRESH_INTERVAL); 

} 

else  { 

ontologyRefreshlnterval  =  null; 

} 

_agents.add(_tasksAgent  =  new  Tasks(_gh5KB,  "tasks_"  +_orgName,  ontologyRefreshlnterval,  _osb,  this)); 

_absolutePointCls  =  _gh5KB.getCls("AbsolutePoint"); 
loadObjectltemsOntoMap(); 

try  { 

_gui.raiseBattlefieldObject(_orgName); 

}  catch  (  FriendlyOrgGUl.UnknownObjectNameException  e  )  { 

Diagnostics. domainEvent("The  map  doesn't  show  the  organisation  of  interest!",  this); 

} 

displayMostRecentTask(); 

//  Make  the  GUI  visible  depending  on  the  value  of  the  interactiveApp 
//  property.  This  is  necessary  if  the  agent  isn't  loaded  from  the  AgentLoader. 
if  ( Jslnteractive  )  { 
if  (  visible  ) 

_gui.setVisible(true); 
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} 

} 

I** 

*  Iterates  through  the  list  of  known  object  items,  placing  each  one  on  the  map. 

**  i 

private  void  loadObjectltemsOntoMap()  { 

Iterator  objltmlter  =  _gh5KB.getCls("Objectltem").getlnstances().iterator(); 

CIs  facilityCIs  =  _gh5KB.getCls("Facility"); 

CIs  featureCIs  =  _gh5KB.getCls("Feature"); 

CIs  materielCIs  =  _gh5KB.getCls("Materiel"); 

CIs  organisationCIs  =  _gh5KB.getCls("Organisation"); 

CIs  personCIs  =  _gh5KB.getCls("Person"); 

CIs  unitCIs  =  _gh5KB.getCls("Unit"); 

while  (  objltmlter.hasNext() )  { 

Instance  oi  =  (lnstance)objltmlter.next(); 
if  ( oi.instanceOf(unitCls) ) 

loadObjectltemOntoMap(oi,  "U"); 
else  if  (  oi.instanceOf(organisationCls) ) 
loadObjectltemOntoMap(oi,  "O"); 
else  if  (  oi.instanceOf(facilityCls) ) 
loadObjectltemOntoMap(oi,  "F"); 
else  if  (  oi.instanceOf(featureCls) ) 
loadObjectltemOntoMap(oi,  "f"); 
else  if  (  oi.instanceOf(materielCls) ) 
loadObjectltemOntoMap(oi,  "M"); 
else  if  (  oi.instanceOf(personCls) ) 
loadObjectltemOntoMap(oi,  "P"); 
else 

throw  new  ErrorfY"'  +  oi.getDirectType().getName()  +  "V  not  modeled  as  a  subtype  of  Objectltem."); 

} 

} 

I** 

*  Places  a  specified  object  item  on  the  map. 

*  @param  oi  The  battlefield  object  {@link  Instance}  to  place  on  the  map. 

*  @param  symbol  The  display  symbol  for  the  object  item. 

**  j 
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private  void  loadObjectltemOntoMap(lnstance  oi,  String  symbol)  { 

Instance  location  =  _gh5KB.getCurrentLocation(oi); 

if  ( location  ==  null  ||  !  location. getDirectType().equals(_absolutePointCls) ) 

return; 

Double  lat  =  _gh5KB.getFloatSlot(location,  "latitudeCoordinate"); 

Double  Ion  =  _gh5KB.getFloatSlot(location,  "longitudeCoordinate"); 
if  ( !  _gui.onMap(lat,  Ion) ) 

return; 

String  oiName  =  _gh5KB.getObjectltemName(oi); 
int  affiliation  =  getAffiliation(oiName); 

_gui.addBattlefieldObject(lat,  Ion,  symbol,  oiName,  affiliation); 

} 

I** 

*  Displays  the  most  recent  <code>ActionTask</code>  {@link  Instance}  associated  with  the  organisation. 

*  If  the  organisation  has  no  associated  tasks,  clears  the  display  area. 

**  i 

private  void  displayMostRecentTask()  { 

Instance  t  =  _gh5KB.currentTask(_org); 
if  ( t  ==  null )  { 

_gui.setTask("(none)"); 

return; 

} 

String  taskName  =  _gh5KB.getStringSlot(t,  "name"); 

_gui.setTask(taskName  ==  null  ?  "(no  text)"  :  taskName.trim()); 

} 

I** 

*  Returns  a  constant  from  {@link  FriendlyOrgGUI}  that  indicates  a  battlefield  object's  affiliation. 

*  @param  objectltemName  The  name  of  the  battlefield  object  whose  affiliation  is  to  be  determined. 

*  @return  A  constant  from  {@link  FriendlyOrgGUI}  that  indicates  a  battlefield  object's  affiliation:  {@link  FriendlyOrgGUI#FRIENDLY}, 

*  {@link  FriendlyOrgGUI#HOSTILE},  or{@link  FriendlyOrgGUI#SELF}. 

**  j 

private  int  getAffiliation(String  objectltemName)  { 
if  (  objectltemName. equals(_orgName) ) 

return  FriendlyOrgGUI. ObjectltemAffiliation. SELF; 

Instance  oi  =  _gh5KB.getObjectltem(objectltemName); 

return  _gh5KB.isHostile(oi)  ?  FriendlyOrgGUI. ObjectltemAffiliation. HOSTILE  :  FriendlyOrgGUI. ObjectltemAffiliation. FRIENDLY; 
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*  Unmarshals  a  map  specification  and  returns  the  Java  objects  for  that  specification. 

*  @param  specURL  The  URL  of  an  XML  document  containing  a  {@link  MapSpec}. 

*  @return  A  {@link  MapSpec}  instance  unmarshalled  from  <code>specURL</code>. 

*  @throws  InvalidMapSpecificationException  If  <code>specURL</code>  does  not  exist,  can't  be  opened,  or  contains  content  that 

*  can't  be  unmarshalled  into  a  <code>MapSpec</code>. 

**  j 

private  MapSpec  mapSpec(URL  specURL)  throws  InvalidMapSpecificationException  { 

try  { 

MapSpec  spec  =  MapSpecUnmarshaller.unmarshal(specURL.openStream(),  true); 
return  spec; 

}  catch  ( java.io.lOException  e  )  { 

throw  new  lnvalidMapSpecificationException("Cannot  unmarshal  map  specification  "  +  specURL.toString(),  e); 

} 

} 

I** 

*  Implements  the  {@link  OrganisationObserver#getOrganisation()}  method  of  the  {@link  OrganisationObserver}  interface. 

*  @return  The  {@linkplain  Instance  organisation  instance}  that  controls  this  <code>FriendlyOrg</code>. 

**  j 

public  Instance  getOrganisation()  { 
return  _org; 

} 

I** 

*  Returns  the  {@link  OntologySQLBinding}  associated  with 

*  this  instance. 

*  @return  The  {@link  OntologySQLBinding}  associated  with 

*  this  instance. 

**  j 

OntologySQLBinding  getOSB()  { 

return  _osb; 

} 

j ** 

*  Returns  the  latitude  of  the  northwest  corner  of  this  organisation's  map. 

*  @return  The  latitude  of  the  northwest  corner  of  this  organisation's  map. 

**  j 

public  double  getNWLatitude()  { 
return  _gui.getNWLatitude(); 
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} 

I** 

*  Returns  the  longitude  of  the  northwest  corner  of  this  organisation's  map. 

*  @return  The  longitude  of  the  northwest  corner  of  this  organisation's  map. 

**  i 

public  double  getNWLongitude()  { 
return  _gui.getNWLongitude(); 

} 

jit* 

*  Returns  the  latitude  of  the  center  of  this  organisation's  map. 

*  @return  The  latitude  of  the  center  of  this  organisation's  map. 

**  i 

public  double  getCenterLatitude()  { 
return  _gui.getCenterLatitude(); 

} 

I** 

*  Returns  the  longitude  of  the  center  of  this  organisation's  map. 

*  @return  The  longitude  of  the  center  of  this  organisation's  map. 

**  j 

public  double  getCenterLongitude()  { 
return  _gui.getCenterLongitude(); 

} 

jit* 

*  Returns  the  knowledge  base  associated  with  this  instance. 

*  @return  The  knowledge  base  associated  with  this  instance. 

**  j 

public  GH5KB  getKB()  { 
return  _gh5KB; 

} 

j ** 

*  Determines  whether  a  battlefield  object  is  visible  to  this  <code>FriendlyOrg</code>. 

*  @param  objectltemName  The  name  of  a  battlefield  object. 

*  @return  True  if  the  name  refers  to  an  {@link  Instance}  of  an  <code>Objectltem</code>  that  is  visible  to  this 

*  <code>FriendlyOrg</code>  (which  currently  means  on  the  map,  there  being  no  features),  false  if  not. 

**  j 

public  boolean  isVisible(String  objectltemName)  { 
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Instance  oi  =  _gh5KB.getObjectltem(objectltemName); 
if  (  oi  ==  null ) 
return  false; 

Instance  location  =  _gh5KB.getCurrentLocation(oi); 
if  ( location  ==  null ) 
return  false; 

Double  lat  =  _gh5KB.getFloatSlot(location,  "latitudeCoordinate"); 

Double  Ion  =  _gh5KB.getFloatSlot(location,  "longitudeCoordinate"); 
return  _gui.onMap(lat,  Ion); 

} 

/**  The  set  of  threat  response  notifications  currently  visible.  7 
private  Set_TRNsDisplayed  =  new  HashSet(); 

jit* 

*  Responds  to  requests  from  <code>Observable</code>s.  Currently  these  requests  fall  into  the  following  categories: 

*  <ul> 

*  <li>Threat  perceptions  from  the  {@link  ThreatPerceptionAgent}.</li> 

*  <li>Threat  response  notifications  from  the  {@link  ThreatResponseAgent}.</li> 

*  <li>Results  of  searches  for  other  agents  of  various  types. </li> 

*  <li>User  interface  requests. </li> 

*  <li>Requests  to  shut  down  the  application  (which  may  or  may  not  come  from  the  user  interface). </li> 

*  </ul> 

**  i 

public  void  update(Observable  o,  Object  arg)  { 
if  (  arg  instanceof  ThreatResponseNotification  )  { 

ThreatResponseNotification  trn  =  (ThreatResponseNotification)arg; 

//  If  user  is  already  viewing  this  threat  response  notification,  ignore  it. 
synchronized  (  TRNsDisplayed  )  { 
if  ( _TRNsDisplayed.contains(trn) ) 
return; 

_TRNsDisplayed.add(trn); 

} 

if  (  visible  ) 

new  ThreatNotificationGUI(_gui,  this,  _gh5KB,  trn); 

} 

else  if  (  arg  instanceof  ThreatPerception  )  { 

respondToThreatPerception((ThreatPerception)arg); 
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else  if  (  arg  instanceof  Tasks. OverviewAgentsSearch  )  { 

_gui. setFlashCapability(((Tasks. OverviewAgentsSearch)arg). agents. size()  >  0); 

} 

else  if  (  arg  instanceof  ThreatNotificationGUI. Completed  )  { 

respondToThreatNotificationGUICompletion((ThreatNotificationGUI.Completed)arg); 

} 

else  if  (  arg  instanceof  String  &&  ((String)arg).equals(FLASH_MESSAGE) )  { 
_tasksAgent.sendFlashRequestToOverviewAgents(); 

} 

else  if  (  arg  instanceof  String  &&  ((String)arg).equals(SHUTDOWN_MESSAGE) )  { 
for  ( Iterator  alter  =  _agents.iterator();  alter.hasNext();  ) 
((C4IAgent)alter.next()).stop(); 

if  ( Jslnteractive  ) 

System. exit(0); 

} 

else  if  (  arg  instanceof  String  )  { 

_gui.addKBUpdate((String)arg); 

} 

else  if  (  arg  instanceof  GeoPosition  )  { 

GeoPosition  gp  =  (GeoPosition)arg; 

Double  lat  =  new  Double(gp.getLatitude().doubleValue()); 

Double  Ion  =  new  Double(gp.getLongitude().doubleValue()); 

String  objName  =  gp.getObjName(); 

try  { 

_gui.moveBattlefieldObject(objName,  lat,  Ion); 

}  catch  (  FriendlyOrgGUl.UnknownObjectNameException  e  )  { 

//  Object  wasn't  on  map.  Add  it  if  it  should  be. 
if  ( _gui.onMap(lat,  Ion) )  { 

//  Should  determine  the  symbol. 

_gui.addBattlefieldObject(lat,  Ion,  "U",  objName,  getAffiliation(objName)); 

} 

} 

} 

else  { 

throw  new  Error("Unknown  arg  to  update: "  +  arg.getClass().getName()); 

} 

} 

private  void  setCourseOfAction(CourseOfAction  coa)  { 
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Diagnostics. domainEvent("Accepted  COA="  +  coa.description(),  this); 

CIs  actionTaskCls  =  _gh5KB.getCls("ActionTask"); 

List  c4IEntities  =  coa.asC4IModel(); 

for  ( Iterator  elter  =  c4IEntities.iterator();  elter.hasNext();  )  { 

Instance  c4lentity  =  (lnstance)elter.next(); 
if  (  c4lentity.instanceOf(actionTaskCls) )  { 

String  vpc  =  _gh5KB.getCodeSlot(c4lentity,  "activityCode"); 

String  cc  =  _gh5KB.getCodeSlot(c4lentity,  "categoryCode"); 

_gui.setTask(cc  +  "  +  vpc); 

return; 

} 

} 

Diagnostics. errorfCan't  display  COA:  No  ActionTask",  this); 

} 

private  void  respondToThreatPerception(ThreatPerception  tp)  { 

String  orgName  =  _gh5KB.getObjectltemName(tp.getOrganisation()); 
boolean  isThreat  =  tp.getlsThreatened(); 
synchronized(  threats  )  { 
if  ( isThreat )  { 

if  ( !  _threats.contains(orgName) ) 

_threats.add(orgName); 

} 

else  { 

if  ( !  _threats.contains(orgName) )  { 

Diagnostics. error("Received  threat  cancellation  for\""  +  orgName  +  but  it  isn't  recorded  as  a  threat.",  this); 
return; 

} 

_threats.remove(orgName); 

} 

} 

_gui.setThreatened(isThreat,  orgName); 

} 

private  void  respondToThreatNotificationGUICompletion(ThreatNotificationGUI. Completed  c)  { 

CourseOfAction  selectedCoA  =  c.getCourseOfAction(); 
if  (  selectedCoA  !=  null )  { 

setCou  rseOfAction  (selectedCoA); 
if  ( _osb  !=  null )  { 
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try  { 

List  entities  =  selectedCoA.asC4IModel(); 

_osb.savelnstances(entities); 

List  eClses  =  new  LinkedList(); 

for  ( Iterator  elter  =  entities. iterator();  elter.hasNext(); ) 

eClses. add(((lnstance)elter.next()).getDirectType().getName()); 
_gui.addKBUpdate("("  +  StringPA.join(eClses, ", ")  + 

}  catch  (  BindingException  e  )  { 

Diagnostics. noteException(e,  this); 

} 

} 

} 

_TRNsDisplayed.remove(c.getThreatResponseNotification()); 

} 

/**  Stores  the  list  of  holdings  of  the  organisation.  */ 
private  List  holdingList  =  null; 

jit* 

*  Returns  the  number  of  holding  types  possessed  by  the  organisation. 

*  @return  The  number  of  holding  types  possessed  by  the  organisation. 

**  j 

int  getHoldingTypesCount()  { 
if  (  holdingList  ==  null ) 

holdingList  =  new  LinkedList(_org.getOwnSlotValues(_gh5KB.getSlot("has-Holding"))); 
return  _holdingList.size(); 

} 

jit* 

*  Returns  the  holding  quantity  for  the  i'th  row  in  the  holding  list. 

*  @param  row  An  index  (zero-based)  into  the  holding  list. 

*  @return  An  Integer  representing  the  holding  quantity  for  the  i'th  row  in  the  holding  list. 

**  j 

Object  getHoldingCount(int  row)  { 

Instance  holding  =  (Instance )_holdingList.get(row); 
return  _gh5KB.getlntSlot(holding,  "totalQuantity"); 

} 

j ** 

*  Returns  the  number  of  threats  this  organisation  perceives. 

*  @return  The  number  of  threats  this  organisation  perceives. 
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public  int  getThreatCount()  { 
return  _threats.size(); 

} 

I** 

*  Returns  the  name  of  the  <i>i</i>'th  threat  to  this  organisation. 

*  @param  i  An  index  (zero-based)  into  the  threats. 

*  @return  The  name  of  the  <i>i</i>'th  threat  to  this  organisation. 

**  j 

public  String  getThreat(int  i)  { 
return  (String)  threats.get(i); 

} 

I** 

*  Returns  the  holding  type  for  the  i'th  row  in  the  holding  list. 

*  <p>This  implementation  isn't  great;  the  parameter  should  be  the 

*  holding  type.  But  I'm  still  learning  about  Swing  tables. 

*  @param  row  An  index  (zero-based)  into  the  holding  list. 

*  @return  A  String  representing  the  holding  type  for  the  i'th  row  in  the  holding  list. 

**  j 

Object  getHoldingType(int  row)  { 

Instance  holding  =  (Instance )_holdingList.get(row); 

Instance  objType  =  (lnstance)holding.getOwnSlotValue(_gh5KB.getSlot("holding-is-constrained-to-ObjectType")); 
return  _gh5KB.getStringSlot(objType,  "name"); 

} 

j ** 

*  Signals  that  a  method  has  been  given  an  organisation  name  that  is  not 

*  recognized. 

**  j 

public  class  UnknownOrgNameException  extends  Exception  { 

j ** 

*  Constructs  an  <code>UnknownOrgNameException</code>  instance  with 

*  a  string  that  by  convention  is  the  name  of  the  unknown  organisation. 

*  @param  orgName  The  name  of  an  unknown  organisation. 

**  j 

UnknownOrgNameException(String  orgName)  { 
super(orgName); 

} 
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} 

I** 

*  Signals  that  the  map  specification  was  invalid. 

**  i 

public  class  InvalidMapSpecificationException  extends  Exception  { 

public  lnvalidMapSpecificationException(String  mapSpec,  Throwable  th)  { 
super(mapSpec,  th); 

} 

public  lnvalidMapSpecificationException(String  mapSpec)  { 
super(mapSpec); 

} 

} 

} 

3.3.  Class  FriendlyOrgGUI 

The  FriendlyOrgGUI  class  encapsulates  the  main  window  of  the  decision  support  application.  It  is  built  by  extending  the  Java  SWING 
class  Jframe.  Its  contents  maintain  the  various  components  of  the  user  interface. 

The  FriendlyOrgGUI  constructor  receives  as  a  parameter  an  instance  of  a  FriendlyOrg.  It  maintains  this  instance  through  a  Notifier,  which 
is  an  abstraction  to  support  one  instance  notifying  another  using  Java’s  Observer/Observable  implementation  of  the  Model-View- 
Controller  paradigm.  (FriendlyOrgGUI  cannot  itself  be  Observable,  because  Observable  is  a  class  and  FriendlyOrgGUI  already  extends  class 
Jframe.) 

Public  methods  of  FriendlyOrgGUI  allow  control  of  the  user  interface:  moving  battlefield  objects,  changing  the  C2  display  area,  etc. 
Note  that  FriendlyOrgGUI  is  not  a  public  class,  as  its  functionality  is  not  (and  must  not  be)  needed  outside  the  FriendlyOrg  package. 

package  ida.bh.cro.friendlyorg; 

import  java. util. HashMap; 

import  javax.  swing.*; 

import  javax. swing. border.Border; 

import  javax. swing. event. ListSelectionEvent; 

import  javax. swing. event. ListSelectionListener; 

import  javax. swing. event.TableModelEvent; 

import  javax. swing. event.TableModelListener; 

import  javax. swing. table.AbstractTableModel; 

import  java. awt.*; 
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import  java. awt.event.ActionEvent; 
import  java. awt. event. ActionListener; 
import  java. awt. event. WindowAdapter; 
import  java. awt. event. WindowEvent; 

import  ida.sd.adt.Notifier; 
import  ida.sd.pa.GUI; 
import  ida.sd.map.*; 
import  ida.sd.map.mapspec.*; 

I** 

*  The  <code>FriendlyOrgGUI</code>  class  provides  the  user  interface  for  a  friendly  organisation.  Each  instance  of  the  class  represents  the  GUI 

*  for  a  particular  organisation.  The  GUI  maintains: 

*  <ul> 

*  <li>A  map  that  displays  battlefield  objects. </li> 

*  <li>A  table  of  the  organisation's  holdings. </li> 

*  </ul> 

*  The  secrets  encapsulated  by  the  GUI  are: 

*  <ol> 

*  <li>The  appearance  of  the  map.</li> 

*  <li>The  appearance  of  a  battlefield  object  displayed  on  the  map.</li> 

*  </ol> 

**  j 

class  FriendlyOrgGUI  extends  JFrame  { 

private  final  static  Integer  BO  LAYER  =  new  Integer(l); 

private  final  static  Font  UNIT  LABEL  FONT  =  new  Font("Serif",  Font. BOLD,  18); 

private  final  static  Border  ETCHED  BORDER  =  BorderFactory.createEtchedBorder(); 

private  final  static  Border  FRIENDLY_OBJ_BORDER  =  BorderFactory.createRaisedBevelBorder(); 
private  final  static  Border  HOSTILE_OBJ_BORDER  =  BorderFactory.createLoweredBevelBorder(); 

/**  The  pane  that  stores  the  map  and  the  battlefield  objects.  The  map  is  stored  in  layer  0.  The  objects  are  in  layer  1.  */ 
private  MapPane  mapPane; 

/**  The  actual  map.  */ 
private  MapDisplay  map; 

/**  A  record  of  the  objects  on  the  map.  Each  name  is  mapped  to  the  Swing  component  that  displays  it.  7 
private  HashMap  _objectsOnMap  =  new  HashMap(); 

/**  Displays  the  most  recent  task  for  the  organisation.  7 
private  JTextArea  _mostRecentTask  =  new  JTextArea(1,  30); 

/**  Displays  knowledge  base  updates  the  organisation  has  received.  7 
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private  JTextArea  _kbllpdates  =  new  JTextArea(4  ,30); 

/**  Lets  the  user  flash  the  organisation's  location.  7 

private  JButton  _flashLoc  =  new  JButton("Flash  Location"); 

/**  Displays  the  organisation's  holdings.  7 
private  JTable  _holdings; 

/**  Displays  threats  to  the  organisation.  7 
private  JTable  _threats; 

/**  A  wrapper  around  the  observer  to  be  notified  when  the  frame  is  closed.  7 
private  Notifier  notifier; 

/**  The  friendly  organisation  that  controls  this  GUI.  7 
private  FriendlyOrg  _associatedFriendlyOrg; 

jit* 

*  Constructs  a  <code>FriendlyOrgGUI</code>  instance. 

*  @param  organisation  The  friendly  organisation  that  controls  this  GUI. 

*  @param  organisationName  A  human-readable  string  describing  the  organisation. 

*  @param  mapSpec  The  specification  of  the  map  to  be  used. 

**  j 

public  FriendlyOrgGUI(FriendlyOrg  organisation,  String  organisationName,  MapSpec  mapSpec)  { 
super(organisationName  + "  Monitor"); 

_notifier  =  new  Notifier((java.util.Observer)organisation); 

_associatedFriendlyOrg  =  organisation; 

Container  contentPane  =  getContentPane(); 

contentPane.setLayout(new  BoxLayout(contentPane,  BoxLayout.Y_AXIS)); 
contentPane. add(GUI.VERTICAL_GAP); 

//  Create  and  set  up  the  map  pane. 

ImageMap  m; 

try  { 

m  =  new  ImageMap(mapSpec); 

}  catch  ( java. net. MalformedURLException  e  )  { 

throw  new  java. lang.lllegalArgumentException("Malformed  URL  \""  +  mapSpec.getMapURL()  +  "  +  e.getMessage()); 

} 

map  =  new  MapDisplay(m); 
mapPane  =  new  MapPane(map); 

mapPane.setBorder(BorderFactory.createEmptyBorder()); 
mapPane.  setAlignmentY(0.  Of); 

II  Add  map  pane,  and  controls,  to  frame. 
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Box  mapBox  =  new  Box(BoxLayout.X_AXIS); 
contentPane.add(mapBox); 

mapBox. add(mapPane); 

mapBox. add(Box.createRigidArea(new  Dimensional 0,  0))); 

Box  controlsBox  =  new  Box(BoxLayout.Y_AXIS); 

controlsBox.setAlignmentY(O.Of); 

mapBox.  add(controlsBox); 

_flashLoc.setEnabled(false); 

_flashLoc.addActionListener(new  ActionListener()  { 
public  void  actionPerformed(ActionEvent  e)  { 
_notifier.signal(FriendlyOrg.FLASH_MESSAGE); 

} 

}); 

_flashLoc.setAlignmentX(O.Of); 
controlsBox.  add(_flashLoc); 
controlsBox. add(Box.createVerticalGlue()); 

ThreatDisplay  td  =  new  ThreatDisplay(this,  organisationName); 

td.setAlignmentX(O.Of); 

controlsBox. add(td); 

//  Make  a  new  container  for  the  portion  of  the  GUI  below  the  map. 
Box  bottomDisplay  =  new  Box(BoxLayout.X_AXIS); 
contentPane.add(Box.createRigidArea(new  Dimension(0,  5))); 
contentPane.add(bottomDisplay); 

bottomDisplay. add(new  HoldingsTable()); 

//  Now  add  the  C4I  information  in  a  vertical  box  with  glue  that  shoves 
//  the  information  to  the  box's  top. 

Box  c4iBox  =  new  Box(BoxLayout.Y_AXIS); 
c4iBox.add(new  C4IDisplay()); 
c4iBox.add(Box.createVerticalGlue()); 

bottomDisplay.add(c4iBox); 

//Add  listener  for  window-closing  event. 
addWindowListener(new  Window Adapter()  { 
public  void  windowClosing(WindowEvent  e)  { 

_notifier.signal(FriendlyOrg.SHUTDOWN_MESSAGE); 

} 

}); 
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pack(); 


} 

I** 

*  Returns  true  iff  a  location  is  on  the  map. 

*  @param  latitude  The  latitude  coordinate,  in  decimal  degrees. 

*  @param  longitude  The  latitude  coordinate,  in  decimal  degrees. 

**  j 

public  boolean  onMap(Double  latitude,  Double  longitude)  { 
return  map.onMap(latitude,  longitude); 

} 

jit* 

*  Puts  a  named  object  on  the  map  at  a  specified  location. 

*  If  the  location  is  off  the  map,  ignores  the  object. 

*  @param  lat  The  latitude  of  the  object. 

*  @param  Ion  The  longitude  of  the  object. 

*  @param  objType  The  type  of  the  object.  Currently  this  is  a  single-character  string,  and  it's  used  as  the  object's  label. 

*  @param  objName  The  name  of  the  object.  The  name  is  used  to  refer  to  the  object  in  subsequent  calls  to 

*  <code>FriendlyOrgGUI</code>  methods. 

*  @param  affiliation  A  value  from  class  <code>ObjectltemAffliation</code>  indicating  the  object's  relationship  to  the  organization 

*  controlling  the  map. 

**  j 

public  void  addBattlefieldObject(Double  lat,  Double  Ion,  String  objType,  String  objName,  int  affiliation)  { 
if  ( !  map.onMap(lat,  Ion) ) 

return; 

JLabel  battlefieldObject  =  new  JLabel(objType,  SwingConstants.LEFT); 

battlefieldObject.setBorder(BorderFactory.createEmptyBorder()); 

battlefieldObject.setVerticalAlignment(JLabel.TOP); 

Color  backgroundColor; 
switch  (  affiliation  )  { 
case  ObjectltemAffiliation.SELF: 
backgroundColor  =  Color.BLUE; 
battlefieldObject. setForeground(Color.CYAN); 
battlefieldObject.setBorder(FRIENDLY_OBJ_BORDER); 
break; 

case  ObjectltemAffiliation. FRIENDLY: 
backgroundColor  =  Color.BLUE; 
battlefieldObject. setForeground(Color.  WHITE); 
battlefieldObject.setBorder(FRIENDLY_OBJ_BORDER); 
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break; 

case  ObjectltemAffiliation. HOSTILE: 
backgroundColor  =  Color.RED; 
battlefieldObject.setForeground(Color.  WHITE); 
battlefieldObject.setBorder(HOSTILE_OBJ_BORDER); 

break; 

default: 

throw  new  Error("lnvalid  object  item  affiliation"); 

} 

II  The  following  adjustments  to  the  background  color  help  beveled  borders  stand  out. 
float  hsv[]  =  new  float[3]; 

Color.  RGBtoHSB(backgroundColor.getRed(),  backgroundColor.getGreen(),  backgroundColor.getBlue(),  hsv); 
if  (  hsv[1]  >  0.5f ) 
hsv[1]  =  0.5f; 
if  (  hsv[2]  >  0.7f ) 
hsv[2]  =  0.7f; 

battlefieldObject.setBackground(new  Color(Color.HSBtoRGB(hsv[0],  hsv[1],  hsv[2]))); 

battlefieldObject.setFont(UNIT_LABEL_FONT); 

battlefieldObject.setOpaque(true); 

Point  p  =  map.getPoint(lat,  Ion); 

FontMetrics  m  =  getFontMetrics(UNIT_LABEL_FONT); 

int  w  =  m.stringWidth(objType); 

int  h  =  m.getAscent()  +  m.getDescent(); 

Insets  bfi  =  battlefieldObject.getlnsets(); 
battlefieldObject.setBounds(p.x, 

p-y, 

w  +  bfi. left  +  bfi. right, 
h  +  bfi. top  +  bfi. bottom); 
battlefieldObject.setToolTipText(objName); 

mapPane.add(battlefieldObject,  BO_LAYER); 

_objectsOnMap.put(objName,  battlefieldObject); 

} 

I** 

*  Move  a  named  object  to  a  new  location.  If  the  new  location  is  off  the  map,  remove  the  object. 

*  @param  objName  The  name  of  the  object  to  move. 

*  @param  lat  The  new  latitude  of  the  object. 

*  @param  Ion  The  new  longitude  of  the  object. 


C-27 


*  @throws  <code>UnknownObjectNameException</code>  if  the  name  doesn't  refer  to  an  object  on  the  map. 

**  j 

public  void  moveBattlefieldObject(String  objName,  Double  lat,  Double  Ion) 
throws  UnknownObjectNameException  { 

JLabel  obj  =  (JLabel)_objectsOnMap.get(objName); 
if  (  obj  ==  null ) 

throw  new  UnknownObjectNameException(objName); 

if  ( !  map.onMap(lat,  Ion) )  { 

_objectsOnMap.remove(objName); 

mapPane.remove(mapPane.getlndexOf(obj)); 

return; 

} 

obj.setl_ocation(map.getPoint(lat,  Ion)); 

} 

I** 

*  Removes  a  named  object  from  the  map. 

*  @param  objName  The  name  of  the  object  to  move. 

*  @throws  UnknownObjectNameException  If  the  name  doesn't  refer  to  an  object  on  the  map. 

**  j 

public  void  removeBattlefieldObject(String  objName) 
throws  UnknownObjectNameException  { 

JLabel  obj  =  (JLabel)_objectsOnMap.get(objName); 
if  (  obj  ==  null ) 

throw  new  UnknownObjectNameException(objName); 

_objectsOnMap.remove(objName); 

mapPane.remove(mapPane.getlndexOf(obj)); 

} 

j ** 

*  Raises  the  named  object  to  the  top  of  the  display.  In  other  words,  it  becomes  on  top  of  any  other  objects  that  happen  to  occupy  the  same 

*  location. 

*  @param  objName  The  name  of  the  object  to  move. 

*  @throws  UnknownObjectNameException  If  the  name  doesn't  refer  to  an  object  on  the  map. 

**  j 

public  void  raiseBattlefieldObject(String  objName) 
throws  UnknownObjectNameException  { 

JLabel  obj  =  (JLabel)_objectsOnMap.get(objName); 
if  (  obj  ==  null ) 
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throw  new  UnknownObjectNameException(objName); 
mapPane.setPosition(obj,  0); 

} 

I** 

*  Sets  the  most-recent-task  display  area  to  the  specified  text. 

*  @param  task  The  string  that  describes  the  most  recent  task. 

**  j 

public  void  setTask(String  task)  { 

_mostRecentTask.setText(task); 

} 

jit* 

*  Sets  the  knowledge  base  update  display  area  to  the  specified  text. 

*  @param  text  The  string  that  describes  the  update. 

**  j 

public  void  setKBUpdate(String  text)  { 

_kbllpdates.setText(text); 

} 

private  boolean  _ousAdded  =  false; 

j ** 

*  Appends  a  string  to  the  knowledge  base  update  display  area. 

*  @param  text  The  string  to  append. 

**  j 

public  void  addKBUpdate(String  text)  { 
if  ( _ousAdded  ) 

_kbllpdates.append("\n"); 

else 

_ousAdded  =  true; 

_kbllpdates.append(text); 

} 

j ** 

*  Sets  the  threat  state  of  the  organisation. 

*  @param  threatened  If  true,  <code>org</code>  is  a  threat.  If  false,  <code>org</code>  is  not  a  threat. 

*  @param  org  The  name  of  the  organisation  in  question. 

*  @todo  Prioritize  the  threats. 

*  @todo  Do  we  need  parameters? 

**  j 

public  void  setThreatened(boolean  threatened,  String  org)  { 
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//  Update  the  threat  table  display. 

((ThreatTableModel)_threats.getModel()).fireTableDataChanged(); 

} 

I** 

*  Returns  the  threat  state  of  the  organisation. 

*  @return  True  if  the  organisation's  GUI  is  showing  that  it's  threatened,  false  if  not. 

**  j 

public  boolean  getThreatened()  { 
return  _threats.getRowCount()  >  0; 

} 

jit* 

*  Sets  whether  the  user  can  use  the  flash  capability. 

*  @param  enabled  If  true,  the  user  can  use  the  flash  capability. 

*  If  false,  he  cannot. 

**  j 

public  void  setFlashCapability(boolean  enabled)  { 

_flashLoc.setEnabled(enabled); 

} 

j ** 

*  Returns  the  latitude  of  the  northwest  corner  of  this  map. 

**  j 

public  double  getNWLatitude()  { 
return  map.getNorthLat(); 

} 

j ** 

*  Returns  the  longitude  of  the  northwest  corner  of  this  map. 

**  j 

public  double  getNWLongitude()  { 
return  map.getWestLon(); 

} 

j ** 

*  Returns  the  latitude  of  the  center  of  this  map. 

**  j 

public  double  getCenterLatitude()  { 
return  map.getCenterLat(); 

} 
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I** 

*  Returns  the  longitude  of  the  center  of  this  map. 

**  i 

public  double  getCenterLongitude()  { 
return  map.getCenterLon(); 

} 

I** 

*  The  <code>UnknownObjectNameException</code>  class  signals  that  a  method  that 

*  takes  the  name  of  a  battlefield  object  as  an  argument  has  been  invoked  with 

*  a  name  that  hasn't  been  added,  or  has  been  removed. 

**  j 

public  class  UnknownObjectNameException  extends  Exception  { 
UnknownObjectNameException(String  message)  { 
super(message); 

} 

} 

/**  The  column  headings  for  the  holdings  table.  */ 

private  static  Stringf]  _columns  =  { "Holding  Type",  "Total  Quantity" }; 

jit* 

*  The  <code>HoldingsTableModel</code>  class  implements  a  table  model  based 

*  on  the  current  holdings  of  the  associated  friendly  organisation. 

**  j 

private  class  HoldingsTableModel  extends  AbstractTableModel  { 
public  int  getRowCount()  { 

return  _associatedFriendlyOrg.getHoldingTypesCount(); 

} 

public  int  getColumnCount()  { 
return  _columns.  length; 

} 

public  Object  getValueAt(int  row,  int  column)  { 
if  (  column  ==  0  ) 

return  _associatedFriendlyOrg.getHoldingType(row); 

else 

return  _associatedFriendlyOrg.getHoldingCount(row); 

} 

public  String  getColumnName(int  column)  { 
return  _columns[column]; 
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} 

} 

I** 

*  The  <code>ThreatTableModel</code>  class  implements  a  table  model  based 

*  on  the  known  threats  to  the  associated  friendly  organisation. 

**  j 

private  class  ThreatTableModel  extends  AbstractTableModel  { 
public  int  getRowCount()  { 

return  _associatedFriendlyOrg.getThreatCount(); 

} 

public  int  getColumnCount()  { 

return  1; 

} 

public  Object  getValueAt(int  row,  int  column)  { 
return  _associatedFriendlyOrg.getThreat(row); 

} 

} 

I** 

*  The  <code>MapPane</code>  class  is  used  to  hold  the  map  and  the  battlefield  objects  it  contains.  The  class  is  an  extension  of  the 

*  <code>JLayeredPane</code>  class. 

*  <p>Having  the  map  grow  or  shrink  is  undesirable.  This  class  overrides  the  get*Size()  methods  such  that  the  size  --  minimum,  maximum, 

*  or  preferred  --  is  always  the  same. 

**  j 

private  class  MapPane  extends  JLayeredPane  { 

Dimension  _size; 

j ** 

*  Constructs  a  <code>MapPane</code>  instance.  The  size  of  the  instance  is  taken  from  the  size  of  a  parameter  label. 

*  @param  map  A  <code>mapDisplay</code>  whose  size  is  used  as  the  fixed  size  of  the  <code>MapPane</code>. 

**  j 

MapPane(MapDisplay  map)  { 

super(); 

_size  =  map.getSize(); 
add(map,  new  Integer(O)); 

} 

public  Dimension  getMinimumSize()  { 
return  size; 
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} 

public  Dimension  getPreferredSize()  { 
return  size; 

} 

public  Dimension  getMaximumSize()  { 
return  size; 

} 

} 

I** 

*  The  <code>ObjectltemAffiliation</code>  class  provides  the  set  of  valid  values  for  the  <code>affiliation</code>  parameter  of 

*  <code>addBattlefieldObject()</code>. 

**  i 

public  class  ObjectltemAffiliation  { 
public  final  static  int  SELF  =  1; 
public  final  static  int  FRIENDLY  =  2; 
public  final  static  int  HOSTILE  =  3; 

} 

I** 

*  The  <code>HoldingsTable</code>  class  encapsulates  the  display  of  the  holdings  table. 

**  j 

private  class  HoldingsTable  extends  JScrollPane  { 

jit* 

*  Creates  a  <code>HoldingsTable</code>.  Has  the  side  effect 

*  of  setting  {@link  #_holdings}  to  a  newly-created  {@link  JTable}. 

**  j 

HoldingsTableO  { 

super(); 

_holdings  =  new  JTable(new  HoldingsTableModel()); 
setViewportView(_holdings); 

_holdings.getColumnModel().getColumn(0).setMinWidth(180); 

_holdings.getColumnModel().getColumn(1  ).setMinWidth(1 00); 

setPreferredSize(new  Dimension(300,  200)); 

setBorder(BorderFactory.createTitledBorder(ETCHED_BORDER,  "Organisation  Holdings")); 

} 

} 

I** 

*  The  <code>C4IDisplay</code>  class  extends  <code>JPanel</code>  to  provide  a  panel  whose  maximum  height  is  always  the  same  is  the 
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*  preferred  height,  which  in  turn  is  always  computed  from  the  sum  of  the  heights  of  its  non-label  components. 

**  j 

private  class  C4IDisplay  extends  JPanel  { 

jit* 

*  Creates  a  <code>C4IDisplay</code>  containing: 

*  <ul> 

*  <li>The  most  recent  task.</li> 

*  <li>Ontology  updates  received. </li> 

*  </ul> 

**  / 

C4IDisplay()  { 

super(new  GridBagLayout()); 

setBorder(BorderFactory.createTitledBorder(ETCHED_BORDER,  "C4I  Display")); 
GUI.addl_abeledComponent(this,  0,  "Most  Recent  Task:  ",  _mostRecentTask); 

JScrollPane  kbllpdatesScrollPane  =  new  JScrollPane(_kbUpdates); 

kbUpdatesScrollPane.setVerticalScrollBarPolicy(JScrollPane.VERTICAL_SCROLLBAR_AS_NEEDED); 
GUI.addLabeledComponent(this,  1,  "KB  Updates: ",  kbUpdatesScrollPane); 

} 

jit* 

*  Gets  the  preferred  size.  The  height  is  computed  as  the  sum  of  all  non-label  components,  plus  a  small  amount  for 

*  inter-component  spacing. 

**  j 

public  Dimension  getPreferredSize()  { 
int  height  =  0; 

Component[]  components  =  getComponents(); 
for  ( int  i  =  0;  i  <  components. length;  i++  )  { 
if  ( !  (components[i]  instanceof  JLabel) ) 

height  +=  ((JComponent)components[i]).getPreferredSize().  height; 

} 

Insets  i  =  getlnsets(); 
height  +=  i.top  +  i. bottom; 

return  new  Dimension(super.getPreferredSize().width,  height  +  GUI. ROW_GAP*(components. length  - 1)); 

} 

j ** 

*  Gets  the  maximum  size  using  the  preferred  size  as  height  and  the  maximum  size  as  width. 

**  j 

public  Dimension  getMaximumSize()  { 
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return  new  Dimension(super.getMaximumSize(). width,  getPreferredSize(). height); 

} 

} 

II  The  following  section  concerns  the  display  of  threats. 

/**  Maximum  number  of  threats  a  scroll  pane  should  show.  */ 

private  final  static  int  THREATS  DISPLAYED  =  5; 

/**  Maximum  number  of  characters  to  show;  used  to  determine  scroll  pane  width.  */ 
private  final  static  int  THREAT_NAME_MAX_LENGTH  =  20; 

private  static  final  String  NOTHREATLABEL  =  "None"; 
private  static  final  Color  NOTHREATCOLOR  =  Color.BLACK; 
private  static  final  String  THREAT_PRESENT_LABEL  =  "Yes"; 
private  static  final  Color  THREAT  PRESENT  COLOR  =  Color.RED; 

jit* 

*  The  <code>ThreatDisplay</code>  class  encapsulates  the  display  of  threats.  The  list  of  known  threats  is  displayed  in  the 

*  {@link  #_threats}  table.  Other  classes  are  responsible  for  setting  and  modifying  the  rows  in  this  table.  This  class  is  responsible  for 

*  organizing  and  displaying  the  table  and  supporting  components.  The  primary  secret  of  this  class  is  the  format  used  to  display 

*  the  components. 

**  i 

private  class  ThreatDisplay  extends  Box  { 

/**  Shows  succinctly  whether  a  threat  exists.  */ 
private  JLabel  threatPresent; 

/**  Lets  the  user  view  a  threat  in  detail.  */ 
private  JButton  _viewThreat  =  new  JButton("View"); 

jit* 

*  Creates  a  <code>ThreatDisplay</code>.  Has  the  following  side  effects: 

*  <ul> 

*  <li>Sets  {@link  #_threats}  to  a  newly-created  {@link  JTable}.</li> 

*  <li>Sets  {@link  #_threatPresent}  to  {@link  #NO_THREAT_LABEL}  and  {@link  #NO_THREAT_COLOR}. 

*  </ul> 

*  @param  parent  The  parent  GUI.  Needed  for  control  of  dialogs. 

*  @param  exampleName  A  "typical"  organisation  name.  Used  to  determine 

*  the  width  of  the  table. 

*  @todo  The  View  button  should  be  enabled  only  when  threats  are 

*  present. 

**  i 

ThreatDisplay(final  FriendlyOrgGUI  parent,  String  exampleName)  { 
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super(BoxLayout.YAXIS); 

setBorder(BorderFactory.createTitledBorder(ETCHED_BORDER,  "Threats")); 

_threatPresent  =  new  JLabel(NO_THREAT_LABEL); 

add(GUI.VERTICAL_GAP); 

add(_threatPresent); 

II  Set  up  the  threat  table. 

_threats  =  new  JTable(new  ThreatTableModel()); 

_threats.setTableHeader(null); 

_threats.setRowSelectionAllowed(true); 

_threats.getSelectionModel().setSelectionMode(ListSelectionModel.SINGLE_SELECTION); 
if  (  exampleName.lengthO  >  THREAT_NAME_MAX_LENGTH  ) 

exampleName  =  exampleName.substring(0,  THREAT_NAME_MAX_LENGTH); 
int  w  =  getFontMetrics(_threats.getFont()).stringWidth(exampleName); 
int  h  =  _threats.getRowHeight()*THREATS_DISPLAYED; 

_threats.setPreferredSize(new  Dimension(w,  h)); 

JScrollPane  scrollPane  =  new  JScrollPane(  _threats, 

JScrollPane.  VERTICAL_SCROLLBAR_AS_NEEDED, 

JScrollPane.  HORIZONTAL_SCROLLBAR_AS_NEEDED); 

add(GUI.VERTICAL_GAP); 

add(scrollPane); 

II  Add  a  button  to  allow  a  detailed  view  of  a  threat. 

_viewThreat.addActionListener(new  ActionListener()  { 
public  void  actionPerformed(ActionEvent  e)  { 
int  selectedRow  =  _threats.getSelectedRow(); 
if  (  selectedRow  ==  -1  )  { 

JOptionPane.showMessageDialog(parent,  "Select  the  threat.",  "Missing  Input",  JOptionPane.ERROR_MESSAGE); 

return; 

} 

new  ThreatExaminationGUI(_associatedFriendlyOrg,  (String)_threats.getModel().getValueAt(selectedRow,  0)); 

} 

}); 

add(GUI.VERTICAL_GAP); 

add(_viewThreat); 

Insets  i; 

i  =  scrollPane. getlnsets(); 

Dimension  scrollPaneSize  =  new  Dimension(w  +  i.left  +  i. right,  h  +  i.top  +  i. bottom); 
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scrollPane.setPreferredSize(scrollPaneSize); 
i  =  getlnsets(); 

Dimension  threatDisplaySize  =  new  Dimension(scrollPaneSize. width  +  i.left  +  i. right,  scrollPaneSize. height  +  i.top  +  i. bottom); 
setPreferredSize(threatDisplaySize); 

//  Add  a  listener  to  handle  enabling/disabling  the  View  button  and  setting  the  _threatPresent  label. 
_threats.getModel().addTableModelListener(new  TableModelListener()  { 
public  void  tableChanged(TableModelEvent  e)  { 
if  ( _threats.getRowCount()  >  0  )  { 

_threatPresent.setText(THREAT_PRESENT_LABEL); 

_threatPresent.setForeground(THREAT_PRESENT_COLOR); 

_viewThreat.setEnabled(_threats.getSelectedRow()  !=  -1); 

} 

else  { 

_threatPresent.setText(NO_THREAT_LABEL); 

_threatPresent.setForeground(NO_THREAT_COLOR); 

_viewThreat.setEnabled(false); 

} 

} 

}); 

//  Add  a  listener  to  enable/disable  the  View  button  based  on  whether  a  row  of  the  _threats  table  is  selected. 
_threats.getSelectionModel().addListSelectionListener(new  ListSelectionListener()  { 
public  void  valueChanged(ListSelectionEvent  e)  { 

_viewThreat.setEnabled(_threats.getSelectedRow()  !=  -1); 

} 

}); 

//  Initialize  values  by  signaling  a  change. 

((ThreatTableModel)_threats.getModel()).fireTableDataChanged(); 

} 

} 

} 

3.4.  Class  GeoPositionContext 

The  GeoPositionContext  class  supplies  that  portion  of  context  functionality  needed  by  a  friendly  organization.  The  SimState  agent  will 
supply  a  Friendly  Organization  with  infonnation  detected  by  sensors.  The  information  is  supplied  as  an  SLO  “result”  atomic  formula. 
Thus  GeoPositionContext  provides  an  implementation  of  evaluateResultQ  that  extracts  the  information  in  the  fonnula  and  uses  it  to  up¬ 
date  the  Friendly  Organization’s  knowledge  base.  The  update  is  performed  using  callback  methods  found  in  class  FriendlyOrg. 
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package  ida.bh.cro.friendlyorg; 

import  java. util. Iterator; 
import  java. util. Set; 

import  fipaos.ont.fipa.ACL; 

import  fipaos.ont.fipa.FIPACONSTANTS; 

import  ida.sd. Diagnostics; 
import  ida.sd. FIPA.slO.SLO; 
import  ida.sd.gpc.*; 
import  ida.sd. adt.Notifier; 

I** 

*  Class  <code>GeoPositionContext</code>  extends  {@link  AbstractGeoPositionContext}  to  fill  in  those  properties  necessary  in  the  context  of  a 

*  friendly  organisation.  This  class  adds  an  implementation  of  the  <code>evaluateResult()</code>  method  that  effectively  implements  sensing  by 

*  iterating  through  the  result,  which  must  be  a  set  of  positions,  and  invoking  the  owner's  <code>testForLocationChange</code>  method. 

**  i 

public  class  GeoPositionContext 

extends  AbstractGeoPositionContext  { 

/**  The  task  that  contains  the  testForLocationChange()  callback  method.  */ 
private  final  HumanlntelTask  owner; 

/**  Used  to  notify  an  observer  of  GeoPosition  events.  */ 
private  final  Notifier  notifier; 

public  final  static  String  SENSING  FUNCTION  =  "sensing"; 

public  GeoPositionContext(ACL  acl,  HumanlntelTask  owner,  FriendlyOrg  friendlyOrg)  { 
super(acl); 
this. owner  =  owner; 
this. notifier  =  new  Notifier(friendlyOrg); 

} 

public  Boolean  evaluateResult(Object  term,  Object  equivalentTerm)  throws  SLO.EvaluationException  { 

II  Should  verify  that  left-hand  term  is  the  sensing  function. 

Set  positions; 

try  { 

positions  =  (Set)equivalentTerm; 

}  catch  (  ClassCastException  e  )  { 

throw  new  SLO.EvaluationException("Cannot  evaluate  result:  Expected  Set  as  right-hand  term",  e); 

} 

Diagnostics. domainEventfSensed  "  +  positions. size()  +  "  position(s).",  this); 
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//  Iterate  through  the  set.  Let  the  owning  task  test  for  location  changes  of  all  object  items  in  the  set. 
for  ( Iterator  plter  =  positions. iterator();  plter.hasNext();  )  { 

GeoPosition  p  =  (GeoPosition)plter.next(); 
owner.testForLocationChange(p); 
if  (  p.getObjName()  !=  null ) 
notifier.signal(p); 

} 

return  new  Boolean(true); 

} 

jit* 

*  Implements  the  truth  method.  Asserting  or  verifying  truth  makes  no  sense  in  this  context,  so  this  method  always 

*  throws  an  EvaluationException. 

**  j 

public  Boolean  truth(Boolean  truth)  throws  SLO. EvaluationException  { 
throw  new  SLO.EvaluationException("Can't  handle  the  truth."); 

} 

} 

3.5.  Class  Tasks 

The  Tasks  class  is  a  FIPA-OS  agent  started  by  a  FriendlyOrg  instance.  It  isn’t  a  true  agent.  It  encapsulates  asynchronous  functionality, 
for  which  FIPA-OS  has  support  superior  to  Java’s  thread  mechanism. 

Tasks  invokes  an  IdleT ask  as  the  root  task.  This  task  is  implemented  as  a  nested  class  of  Tasks.  IdleT ask  is  a  public  class  (as  is  the  Tasks 
agent,  and  all  other  nested  classes  implementing  tasks).  This  visibility  is  necessary  to  use  FIPA-OS ’s  callback  structure.  FIPA-OS  will 
attempt  to  invoke  a  method  named  doneSimStateSearchAgentTaskQ  when  a  SimStateSearchAgentTask  completes.  For  the  invocation  to 
succeed,  both  the  method  and  its  containing  class  must  be  public. 

Tasks  also  contains  nested  class  OverviewAgentsSearch.  This  class  is  local  to  the  package.  It  is  used  in  MVC  notification. 

package  ida.bh.cro.friendlyorg; 

import  java.io.lOException; 
import  java.io.StringReader; 
import  java. util. Collection; 
import  java. util. LinkedList; 
import  java. util. List; 

//  Import  the  fipa  classes 
import  fipaos.ont.fipa.*; 
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//  We  will  also  need  to  import  agent  classes 
import  fipaos. agent.*; 
import  fipaos. agent.task.Task; 
import  fipaos. agent.task.WaitT ask; 
import  fipaos. ont.fipa.fipaman.AgentID; 

import  fipaos. agent. conversation. Conversation; 

import  ida.sd. Diagnostics; 

import  ida.sd. adt.Notifier; 

import  ida.sd. adt.OrganisationObserver; 

import  ida.sd. FIPA.C4IAgent; 

import  ida.bh.ss.fipa.AbstractFindOverviewAgentsTask; 

import  ida.bh.ss.fipa.SimStateAgentSearchTask; 

import  ida.bh.ss.fipa.FlashRequest; 

import  ida.sd. FIPA.fipaPA; 

import  ida.sd.gh5ontology.GH5KB; 

import  ida.sd. osb.BindingException; 

import  ida.sd. osb.OntologySQLBinding; 

I** 

*  The  <code>Tasks</code>  class  implements  an  agent  that  performs  various  tasks  for  a  {@link  FriendlyOrg}. 

*  <p>The  agent  isn't  a  true  agent,  meaning  that  it  isn't  examining  the  ontology  and  helping  in  decision-making.  FIPA-OS  just  happens  to  be  the 

*  best  way  to  implement  the  necessary  functionality. 

*  <p>The  tasks  this  agent  performs  are  as  follows: 

*  <ol> 

*  <li>lt  initiates  all  appropriate  sensor  tasks. </li> 

*  <li>lt  initiates  periodic  searches  for  {@link  ida.bh.cro. overview. OverviewAgent}s.</li> 

*  <li>On  request,  it  sends  "flash  location"  messages  to  the  {@link  ida.bh.cro. overview. OverviewAgent}s.</li> 

*  </ol> 

*  The  assumption  in  this  model  is  that  sensors  aren't  implemented  by  agents.  Sensing  is  a  low-level  activity  that  feeds  directly  into  a  GH5 

*  data  set.  Rather,  agents  examine  a  GH5  knowledge  base,  looking  for  patterns  of  interest.  Sensing  is  therefore  implemented  through  this  task, 

*  rather  than  as  a  separate  agent. 

**  j 

public  class  Tasks 
extends  C4IAgent  { 

/**  The  agent  type  used  when  registering  with  the  DF.  */ 
public  final  static  String  AGENT  TYPE  =  "fo-tasks-agent"; 

/**  Used  to  notify  the  parent  class  of  events.  */ 
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private  final  Notifier  _notifier; 

/**  A  link  between  the  GH5  ontology  and  an  underlying  DB.  */ 
private  final  OntologySQLBinding  _osb; 

/**  The  interval,  in  milliseconds,  between  the  times  when  the  ontology  is  to  be  refreshed  from  an  underlying  DB.  */ 
private  final  int  kbRefreshlnterval; 

/**  The  name  of  the  organisation  being  modeled.  */ 
private  final  String  orgName; 

/**  {@link  ida.bh.cro. overview. OverviewAgentjs  active  as  of  the  last  search.  7 
private  Collection  _overviewAgents  =  new  LinkedList(); 

/**  The  ID  of  the  {@link  ida.bh.cro.simstate.SimState}  agent  for  this  simulation.  7 
private  AgentID  _simStateAgent; 

/**  The  instance  that  invoked  this  instance.  7 
private  final  OrganisationObserver_orgObserver; 

/**  The  underlying  knowledge  base.  7 

private  final  GH5KB  _gh5KB; 

jit* 

*  Constructs  a  <code>Tasks</code>  instance.  Initializes  fields,  registers  this  agent  with  the  AMS  and  DF,  then  starts  an 

*  {@link  Tasks. IdleTask}  as  the  listener  task. 

*  @param  gh5KB  A  GH5  knowledge  base. 

*  @param  name  The  name  of  the  agent,  which  must  be  unique  across  the  platform. 

*  @param  knowledgeBaseRefreshlnterval  The  interval,  in  seconds,  between  refreshes  of  the  knowledge  base  from  the  underlying  DBMS. 

*  Ignored  if  <code>osb</code>  is  null. 

*  @param  osb  A  binding  between  the  knowledge  base  and  an  underlying  DBMS  being  used  to  populate  the  knowledge  base.  If  null,  no 

*  DBMS  underlies  the  knowledge  base. 

*  @param  o  The  {@link  FriendlyOrg}  that  invoked  this  agent. 

7 

public  Tasks(GH5KB  gh5KB,  String  name,  Integer  knowledgeBaseRefreshlnterval,  OntologySQLBinding  osb,  OrganisationObserver  o)  { 
super(name); 

_gh5KB  =  gh5KB; 

_orgObserver  =  o; 

_ notifier  =  new  Notifier(o); 

_orgName  =  _gh5KB.getObjectltemName(o.getOrganisation()); 
if  ( (_osb  =  osb)  !=  null ) 

_kbRefreshlnterval  =  knowledgeBaseRefreshlnterval. intValue()  *  1000; 

else 

_kbRefreshlnterval  =  0;  II  Needed  'cause  _kbRefresh Interval  is  final. 
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startPushing(); 

registerWithAMS(); 

registerWithDF(AGENT_TYPE); 

setListenerTask(new  ldleTask()); 

} 

jit* 

*  Requests  {@link  ida.bh.cro. overview. OverviewAgentjs  to  flash  the  location  of  the  friendly  organisation  this  application  is  modeling. 

**  i 

public  void  sendFlashRequestToOverviewAgents()  { 

Collection  overviewAgents  =  new  LinkedList(); 
synchronized  ( _overviewAgents  )  { 

overviewAgents. addAII(_overviewAgents); 

} 

FlashRequest.send(this,  _orgName,  overviewAgents); 

} 

I** 

*  The  <code>ldleTask</code>  class  is  the  listener  task  for  the  <code>Task</code>  agent.  Its  roles  are  to: 

*  <ol> 

*  <li>lnitiate  all  appropriate  sensor  tasks. </li> 

*  <li>lnitiate  the  searches  for  {@link  ida.bh.cro. overview. OverviewAgents. </li> 

*  <li>lnitiate  the  search  for  the  {@link  ida.bh.cro.simstate.SimState}  agent. </li> 

*  <li>lnitiate  periodic  refreshes  of  the  knowledge  base  from  the  database,  if  one  is  being  used.</li> 

*  </ol> 

**  i 

public  class  IdleTask  extends  Task  { 

/**  Creates  a  new  <code>ldleTask</code>.  7 
public  ldleTask()  {} 

jit* 

*  Callback  method  invoked  when  the  task  is  initialised.  Starts  three  tasks:  a  {@link  Tasks. FindOverviewAgentsTask}, 

*  a  {@link  SimStateAgentSearchTask},  and  a  {@link  Tasks. KnowledgeBaseRefreshTask}.  This  last  task  is 

*  only  started  if  a  DBMS  is  being  used. 

**  i 

protected  void  startTask()  { 

newTask(  new  FindOverviewAgentsTask() ); 
newTask(  new  SimStateAgentSearchTask() ); 
if  ( _osb  !=  null  ) 
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newTask(  new  KnowledgeBaseRefreshTask() ); 

} 

I** 

*  Callback  method  invoked  when  the  {@link  SimStateAgentSearchTask}  completes.  Starts  the  tasks  that  simulate  sensors. 

*  (Currently  this  is  limited  to  a  {@link  HumanlntelTask}.)  Note  that  it  doesn't  make  sense  to  start  sensing  until  the  <code>SimState</code> 

*  agent  is  found,  because  there  wouldn't  be  anyone  to  receive  or  report  ground  truth. 

*  @param  result  The  agent  ID  of  the  <code>SimState</code>  agent. 

**  j 

public  void  doneSimStateAgentSearchTask(Object  result)  { 

Diagnostics.fipaEvent("SimStateAgentSearchTask  completed.",  this); 

_simStateAgent  =  (AgentlD)result; 

newTask(  new  HumanlntelTask(_gh5KB,  (FriendlyOrg)_orgObserver,  _simStateAgent) ); 

II  Should  also  search  the  ontology  for  other  sensors  this  org  has. 

} 

I** 

*  Callback  method  invoked  when  the  {@link  Tasks. FindOverviewAgentsTask}  completes.  Does  nothing. 

*  @param  t  The  completed  task. 

**  j 

public  void  doneTasks_FindOverviewAgentsTask(Task  t)  { 

Diagnostics.fipaEventfFindOverviewAgentsTask  completed.",  this); 

} 

j ** 

*  Callback  method  invoked  when  the  {@link  Tasks. KnowledgeBaseRefreshTask}  completes.  Does  nothing. 

*  @param  t  The  completed  task. 

**  j 

public  void  doneTasks_FindKnowledgeBaseRefreshTask(Task  t)  { 

Diagnostics.fipaEvent("KnowledgeBaseRefreshTask  completed.",  this); 

} 

} 

j ** 

*  The  <code>FindOverviewAgentsTask</code>  periodically  updates  the  set  of  {@link  ida.bh.cro. overview. OverviewAgent}s  known 

*  to  be  active. 

**  j 

public  class  FindOverviewAgentsTask  extends  AbstractFindOverviewAgentsTask  { 

j ** 

*  Callback  method  invoked  each  time  a  search  for  {@link  ida.bh.cro. overview. OverviewAgent}s  completes.  If  the  set  of  known 

*  <code>OverviewAgent</code>s  has  changed  since  the  last  invocation,  updates  that  set,  and  signals  the  {@link  OrganisationObserver} 
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*  given  to  this  {@link  Task}  of  the  agents  found. 

*  @param  overviewAgents  The  <code>OverviewAgent</code>s  found  in  the  search. 

*  @param  changed  True  if  <code>overviewAgents</code>  differs  from  the  last  time  this  method  was  invoked,  false  if  not  or  if 

*  this  method  is  being  invoked  for  the  first  time. 

**  j 

public  void  utilize(Collection  overviewAgents,  boolean  changed)  { 
if  (  changed  )  { 

synchronized(  _overviewAgents  )  { 

_overviewAgents.clear(); 

_overviewAgents.addAII(overviewAgents); 

} 

_notifier.signal(new  OverviewAgentsSearch(_overviewAgents)); 

} 

} 

} 

jit* 

*  The  <code>KnowledgeBaseRefreshTask</code>  class  implements  a  {@link  Task}  that  periodically  refreshes  the  knowledge  base  from 

*  the  underlying  database. 

**  j 

public  class  KnowledgeBaseRefreshTask  extends  Task  { 

/**  Creates  a  <code>KnowledgeBaseRefreshTask</code>.  */ 
public  KnowledgeBaseRefreshTask()  {} 

j ** 

*  Callback  method  invoked  when  the  task  is  initialised.  Starts  a  {@link  WaitTask}.  When  the  <code>WaitTask</code>  ends,  the 

*  knowledge  base  gets  refreshed. 

**  j 

protected  void  startTask()  { 

Diagnostics.fipaEvent("KnowledgeBaseRefreshTask  started.  Starting  WaitTask.",  this); 
newTask  (  new  WaitTask(_kbRefreshlnterval) ); 

} 

j ** 

*  Callback  method  invoked  when  the  {@link  WaitTask}  started  by  this  task  ends.  Refreshes  the  knowledge  base  from  the  underlying  DB, 

*  then  starts  another  <code>WaitTask</code>. 

*  @param  t  The  <code>WaitTask</code>  that  has  completed. 

**  j 

public  void  doneWaitTask(Task  t)  { 

Diagnostics.fipaEvent("WaitTask  completed.  Updating  knowledge  base.",  this); 
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try  { 

_osb.updateKBfromDB(); 

}  catch  (  BindingException  e  )  { 

Diagnostics. noteException(e,  this); 

} 

Diagnostics.fipaEvent("KB  refresh  completed.  Starting  new  WaitTask.",  this); 
newTask  (  new  WaitTask(_kbRefreshlnterval) ); 

} 

} 

I** 

*  The  <code>OverviewAgentsSearch</code>  class  signals  the  results  of  a  search  for  {@link  OverviewAgentjs. 

**  j 

class  OverviewAgentsSearch  { 

/**  The  {@link  OverviewAgent}s  found  in  a  search.  */ 

Collection  agents; 

jit* 

*  Creates  an  <code>OverviewAgentsSearch</code>.  The  results  of  the  search  are  visible  through  the  {@link  agents}  field. 

*  @param  agents  The  {@link  OverviewAgent}s  found  in  the  search. 

**  j 

OverviewAgentsSearch(Collection  agents)  { 
this. agents  =  agents; 

} 

} 

} 

3.6.  Class  HumanlntelTask 

The  HumanlntelTask  class  implements  a  simulation  of  a  human  observing  his  immediate  battle  space.  A  HumanlntelTask  is  invoked  by 
the  Tasks  agent.  Unlike  other  tasks  that  agent  invokes,  HumanlntelTask  is  not  nested.  The  intelligence  gathering  role  will  eventually  ex¬ 
pand  in  operational  applications  that  expand  the  current  IDA  prototype.  A  decision  was  made  to  keep  HumanlntelTask  separate  from 
other  classes  to  encourage  encapsulation  of  design  decisions, 
package  ida.bh.cro.friendlyorg; 

import  java. util. Calendar; 
import  java. util. Collection; 
import  java. util. Collections; 
import  java. util. GregorianCalendar; 
import  java. util. Iterator; 
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import  java. util. LinkedList; 
import  java. util. List; 
import  java. util. Set; 

II  Import  the  fipa  classes 
import  fipaos.ont.fipa.*; 

//  We  will  also  need  to  import  agent  classes 
import  fipaos. agent.*; 
import  fipaos. agent.task.Task; 
import  fipaos. agent.task.WaitT ask; 
import  fipaos. ont.fipa.fipaman.AgentID; 

import  fipaos. agent. conversation. Conversation; 

import  ida.sd. Diagnostics; 

import  ida.bh.cro.simstate.*; 

import  ida.bh.ss. protocol. RequestReplyProtocol; 

import  ida.sd. adt.Notifier; 

import  ida.sd. Earth; 

import  ida.sd. FIPA.C4IAgent; 

import  ida.sd. FIPA.slO.ParseException; 

import  ida.sd. FIPA.slO.SLO; 

import  ida.sd. FIPA.slO.SLOParser; 

import  ida.sd.gh5ontology.*; 

import  ida.sd.gpc. GeoPosition; 

import  ida.sd. osb.BindingException; 

import  ida.sd. osb.OntologySQLBinding; 

import  ida.sd.ontology.*; 

import  ida.sd. pa. MathPA; 

import  ida.sd.pa.PoissonDistribution; 

I** 

*  The  <code>HumanlntelTask</code>  class  implements  a  task  that  simulates  human  observers  scanning  the  visible  terrain  and  reporting 

*  movement  of  enemy  organisations.  The  limits  of  "visible  terrain"  are  considered  to  be  the  limits  the  map,  and  since  we  don't  have  any  feature 

*  information,  we  consider  the  entire  map  visible. 

*  <p>This  task  is  local  to  the  <code>friendlyorg</code>  package.  It  is  declared  public  to  meet  fipaos  implementation  requirements. 

**/ 

public  class  HumanlntelTask 
extends  Task  { 
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private  final  GH5KB  _gh5KB; 
private  final  PoissonDistribution  _delay; 
private  final  FriendlyOrg  _friendlyOrg; 
private  final  AgentID  _simStateAgent; 
private  final  static  int  MEAN  DELAY  =  30; 

I** 

*  Constructs  a  <code>Humanlntel</code>  instance. 

*  @param  friendlyOrg  The  {@link  FriendlyOrg}  that  invoked  this  task. 

7 

public  HumanlntelTask(GH5KB  gh5KB,  FriendlyOrg  friendlyOrg,  AgentID  simStateAgent)  { 

_gh5KB  =  gh5KB; 

_friendlyOrg  =  friendlyOrg; 

_simStateAgent  =  simStateAgent; 

_delay  =  new  PoissonDistribution(MEAN_DELAY); 

} 

jit* 

*  Callback  method  invoked  when  the  task  is  initialised.  Starts  a  <code>WaitTask</code>, 

*  after  which  the  first  map  examination  is  performed. 

**  j 

protected  void  startTask()  { 

Diagnostics.fipaEvent("HumanlntelTask  started  OK.  Starting  WaitTask",  this); 
newTask(  new  WaitTask(_delay.next()  *  1000) ); 

} 

jit* 

*  Callback  method  invoked  when  the  <code>WaitTask</code>  completes. 

*  Sends  a  request  to  the  SimState  agent  for  all  visible  battlefield  objects. 

**  j 

public  void  doneWaitTask(Task  t)  { 

Diagnostics.fipaEvent("WaitTask  done.  Asking  SimState  agent  for  intel this); 

ACL  request  =  getNewConversation(RequestReplyProtocol.getProtocolName()); 
request.setPerformative(FIPACONSTANTS.  REQUEST); 
request. setOntology(GeoPositionContext.getName()); 
request. setLanguage(SLOParser.getLanguage()); 

String  nw  =  "(position  latitude  "  +  _friendlyOrg.getNWLatitude()  +  "  :longitude  "  +  _friendlyOrg.getNWLongitude()  +  ")"; 
String  center  =  "(position  latitude  "  +  _friendlyOrg.getCenterLatitude()  +  "  :longitude  "  +  _friendlyOrg.getCenterLongitude()  +  ")"; 
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String  reportRequest  =  "("  + 

GeoPositionContext.SENSING_FUNCTION  + 

"  :center "  + 
center  + 

"  :northwest "  + 
nw  + 

"  :report-org-name  V'trueV')"; 

SLO. Content  content; 

try  { 

content  =  SLOParser.parseContent("((action  "  +  _simStateAgent.toString()  +  " "  +  reportRequest  +  true); 
}  catch  (  ParseException  e  )  { 
throw  new  Error(e); 

} 

request. setContentObject(content.toString()); 
request.setReceiverAID(_simStateAgent); 

Diagnostics.fipaEvent("Sending  intel  request "  +  (String)request.getContentObject(),  this); 
forward(request); 


jit* 

*  Callback  method  invoked  when  the  agent  receives  a  message  with  the  INFORM  performative. 

*  Handles  the  message  according  to  its  ontology.  (Currently  only  {@link  GeoPositionContext}  is  recognized.) 

*  @param  conv  The  conversation  containing  the  message. 

**  i 

public  void  handlelnform(Conversation  conv)  { 

Diagnostics. reportHandle(conv,  this); 

ACL  acl  =  conv.getACL(conv.getLatestMessagelndex()); 

if  (  acl.getOntology().equals(GeoPositionContext.getName()) )  { 
handleGeoPositionlnform(acl); 

} 

else  { 

Diagnostics. errorfllnexpected  ontology  "  +  acl.getOntology(),  this); 
sendNotllnderstood(acl); 

} 

int  delay  =  _delay.next(); 

Diagnostics.fipaEvent("Starting  WaitTask  for "  +  delay  +  "  seconds.",  this); 
newTask(  new  WaitTask(delay  *  1000) ); 
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} 

I** 

*  Handles  an  ACL  whose  ontology  is  geo-position.  Extracts,  parses,  and  evaluates  the  ACL's  content,  which  results  in  the  invocation  of 

*  {@link  testForLocationChange}. 

*  @param  acl  An  ACL  whose  ontology  indicates  it's  geoposition  information. 

*  @throws  ParseException  If  the  content  is  syntactically  invalid. 

*  @throws  SLO.EvaluationException  If  the  content  is  semantically  invalid. 

**  j 

private  void  handleGeoPositionlnform(ACL  acl)  { 

if  ( !  acl.getLanguage().equals(SLOParser.getLanguage()) )  { 

Diagnostics. error("Unexpected  language  "  +  acl.getLanguage(),  this); 
sendNotUnderstood(acl); 

return; 

} 

try  { 

SLO. Content  content  =  SLOParser.parseContent((String)acl.getContentObject()); 

Diagnostics.fipaEvent("Received  content "  +  content.toString(),  this); 
content.evaluate(new  GeoPositionContext(acl,  this,  _friendlyOrg)); 

}  catch  (  ParseException  e  )  { 

Diagnostics. noteException(e,  this); 

sendNotUnderstood(acl); 

return; 

}  catch  (  SLO.EvaluationException  e  )  { 

Diagnostics. noteException(e,  this); 
sendNotUnderstood(acl); 

return; 

} 

} 

private  final  static  int  PRECISION  =  5; 

jit* 

*  Callback  method  invoked  in  response  to  evaluation  of 

*  <code>(result  (sensing  ...)  ;(set  (</code>{@link  GeoPosition}<code>1{@link  GeoPosition}<code>2...)))</code> 

*  atomic  formulae  of  the  {@link  GeoPositionContext}  ontology.  This  method  is  invoked  with  a  single  {@link  GeoPosition}  <i>p</i>. 

*  that  contains  the  name  of  a  battlefield  object.  It  tests  whether  the  last  recorded  position  of  that  object  is  different  from  the  one  in  <i>p</i>. 

*  If  so  (or  if  the  object  has  no  known  position)  it  {@linkplain  noteLocationChange  notes  the  change  of  location}. 

*  @param  p  The  {@link  GeoPosition}  of  some  battlefield  object. 

**  j 
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void  testForLocationChange(GeoPosition  p)  { 

float  sensedLatitude  =  p.getLatitude().floatValue(); 
float  sensedLongitude  =  p.getLongitude().floatValue(); 

Instance  objltem  =  _gh5KB.getObjectltem(p.getObjName()); 

Instance  lastRecordedLocation  =  _gh5KB.getCurrentLocation(objltem); 
if  ( lastRecordedLocation  ==  null )  { 

noteLocationChange(objltem,  sensedLatitude,  sensedLongitude); 

return; 

} 

float  lastRecordedLatitude  =  _gh5KB.getFloatSlot(lastRecordedLocation,  "latitudeCoordinate").floatValue(); 
float  lastRecordedLongitude  =  _gh5KB.getFloatSlot(lastRecordedLocation,  "longitudeCoordinate").floatValue(); 

if  ( !  (  MathPA.almostEqual(lastRecordedLatitude,  sensedLatitude,  PRECISION)  && 

MathPA.almostEqual(lastRecordedLongitude,  sensedLongitude,  PRECISION) ) ) 
noteLocationChange(objltem,  sensedLatitude,  sensedLongitude); 

} 

I** 

*  Creates  a  specification  of  a  change  in  location  of  some  battlefield  object,  and  saves  that  specification  in  the  underlying  DBMS. 

*  The  specification  is  encapsulated  using  GH5  entities: 

*  <ol> 

*  <li>An  ObjectltemLocation.</li> 

*  <li>A  ReportingDataAbsoluteTiming: 

*  <ol> 

*  <li>reportingTime  and  reportingDate  are  set  to  the  current  time.</li> 

*  <li>effectiveTime  and  EffectiveDate  are  set  to  the  current  time.</li> 

*  <li>The  duration  is  set  to  1000  seconds.  This  value  is  arbitrary,  and  not  realistic.  Perhaps  it  should  be  based  on  perceived  speed  of 

*  the  object. </li> 

*  <H>effectiveTimePrecisionCode  is  set  to  SECOND.  Given  that  this  is  human  intelligence,  MINUTE  might  be  better.</li> 

*  <li>reliabilityCode  is  set  to  B  (usually  reliable). </li> 

*  <li>sourceTypeCode  is  set  to  EYOBSN  (human  observation). </li> 

*  <li>credabilityCode  is  set  to  RPTPLA  (possible  or  probable). </li> 

*  </ol> 

*  </li> 

*  <li>An  AbsolutePoint,  with  latitude  and  longitude  set  from  parameters. </li> 

*  </ol> 

*  Establishes  entity  relationships  (e.g.,  <code>ObjectltemLocation</code>  <code>is-referenced-to</code>  <code>ReportingData</code>). 

*  @param  obj  The  battlefield  object  whose  location  has  changed. 

*  @param  latitude  The  new  latitude  of  the  battlefield  object. 
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*  @param  longitude  The  new  longitude  of  the  battlefield  object. 

**  j 

private  void  noteLocationChange(lnstance  obj,  float  latitude,  float  longitude)  { 

Calendar  now  =  Calendar.getlnstance(); 

try  { 

//  Create  the  associative  entity. 

Instance  objltemLoc  =  _gh5KB.getCls("Objectlteml_ocation").createDirectlnstance(); 

setObjectlteml_ocationAttributes(obj,  objltemLoc,  (double)latitude,  (double)longitude,  now); 

//  Create  the  reporting  data  that's  associated  with  the 
//  ObjectltemLocation. 

Instance  report  =  _gh5KB.getCls("ReportingDataAbsoluteTiming").createDirectlnstance(); 

_gh5KB.setDateTimeSlots(report,  "reportingDate",  "reportingTime",  now); 

_gh5KB.setDateTimeSlots(report,  "effectiveDate",  "effectiveTime",  now); 

_gh5KB.setlntSlot(report,  "duration",  new  Integer(IOOO));  //  1000  is  arbitrary.  There  are  some  interesting  possibilities  here. 
_gh5KB.setCodeSlot(report,  "effectiveTimePrecisionCode",  "SECOND"); 

_gh5KB.setCodeSlot(report,  "reliabilityCode",  "B"); 

_gh5KB.setCodeSlot(report,  "sourceTypeCode",  "EYOBSN"); 

_gh5KB.setCodeSlot(report,  "credibilityCode",  "RPTPLA"); 

_gh5KB.setCodeSlot(report,  "categoryCode",  "REP"); 

_gh5KB.setCodeSlot(report,  "entityCategoryCode",  "OILOCA"); 

_gh5KB.setCodeSlot(report,  "countinglndicatorCode",  "NO"); 

report.setOwnSlotValue(_gh5KB.getSlot("reporting-data-is-reported-by-Organisation"),  _friendlyOrg.getOrganisation()); 

//  Create  the  new  location. 

Instance  pt  =  _gh5KB.getCls("AbsolutePoint").createDirectlnstance(); 

_gh5KB.setFloatSlot(pt,  "latitudeCoordinate",  new  Double(latitude)); 

_gh5KB.setFloatSlot(pt,  "longitudeCoordinate",  new  Double(longitude)); 

_gh5KB.setCodeSlot(pt,  "angularPrecisionCode",  "SECOND"); 

//  Create  the  relationships. 

objltemLoc. setOwnSlotValue(  gh5KB.getSlot("obj  item  loc-is-referenced-to-ReportingData"),  report); 
obj.addOwnSlotValue(_gh5KB.getSlot("is-geometrically-defined-through-ObjectltemLocation"),  objltemLoc); 
pt.addOwnSlotValue(_gh5KB.getSlot("provides-geometric-definition-for-ObjectltemLocation"),  objltemLoc); 

Diagnostics. domainEvent("Created  new  location  for "  +  _gh5KB.getObjectltemName(obj),  this); 

//  Save  the  instances.  Because  of  DB  integrity  constraints,  order  matters. 

//  It  would  be  better  to  have  osb  determine  the  correct  order,  thereby 
//  removing  knowledge  of  the  DB  from  this  class. 

OntologySQLBinding  osb  =  _friendlyOrg.getOSB(); 
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if  (  osb  ==  null ) 

return; 

osb.savelnstances(new  Instancef]  {  pt,  report,  objltemLoc }); 

//  Place  an  item  in  the  KB  update  area, 
new  Notifier(_friendlyOrg).signal("("  + 

pt.getDirectType().getName()  +  ", "  + 
report.getDirectType().getName()  +  ", "  + 
objltemLoc.getDirectType().getName()  + 

}  catch  ( InvalidCodeException  e  )  { 
throw  new  Error(e); 

}  catch  (  BindingException  e  )  { 

Diagnostics. noteException(e,  this); 

} 

} 

private  void  setObjectlteml_ocationAttributes(lnstance  objltem,  Instance  objltemLoc,  double  latitude,  double  longitude,  Calendar  now)  { 

//  If  the  object  has  a  last  known  location,  compute  speed  and  bearing  angle. 

Collection  prevLocs  =  objltem. getOwnSlotValues(_gh5KB.getSlot("is-geometrically-defined-through-ObjectltemLocation")); 
if  (  prevLocs. size()  ==  0  ) 

return; 

List  prevLocsList  =  new  LinkedList(prevLocs); 

Collections. sort(prevLocsList,  new  RDComparator(_gh5KB,  "provides-applicable-information-for-ObjectltemLocation")); 

Instance  prevObjltemLoc  =  (lnstance)prevLocsList.get(prevLocsList.size()  - 1); 

Instance  prevLocation  =  (lnstance)prevObiltemLoc.getOwnSlotValue(  gh5KB.getSlot("obj  item  loc-is-associated-with-Location")); 

double  prevLat  =  _gh5KB.getFloatSlot(prevLocation,  "latitudeCoordinate").doubleValue(); 
double  prevLon  =  _gh5KB.getFloatSlot(prevLocation,  "longitudeCoordinate").doubleValue(); 

_gh5KB.setFloatSlot(objltemLoc,  "bearingAngle",  new  Double(Earth.angle(prevLat,  prevLon,  latitude,  longitude))); 

Instance  prevLocationRD  =  (lnstance)prevObiltemLoc.getOwnSlotValue(  gh5KB.getSlot("obj  item  loc-is-referenced-to-ReportingData")); 
if  (  prevLocationRD  ==  null ) 

return;  //  Without  timing,  we  can't  compute  speed, 
if  ( !  prevLocationRD. instanceOf(_gh5KB.getCls("ReportingDataAbsoluteTiming") ) ) 
return;  //  We  don't  handle  relative  timing  yet. 

String  prevEffectiveDate  =  _gh5KB.getStringSlot(prevLocation,  "effectiveDate"); 

String  prevEffectiveTime  =  _gh5KB.getStringSlot(prevLocation,  "effectiveTime"); 
if  (  prevEffectiveDate  ==  null  ||  prevEffectiveTime  ==  null  ) 
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return; 

String  etpc  =  _gh5KB.getCodeSlot(prevLocationRD,  "effectiveTimePrecisionCode"); 
if  (  etpc  ==  null  ) 
etpc  =  "SECOND"; 

//  timeDiff  is  in  seconds. 

long  timeDiff  =  (now.getTime().getTime()  -  DateTime.getCalendar(prevEffectiveDate,  prevEffectiveTime).getTime().getTime())/1000; 

//  distance  is  in  kilometers. 

double  distance  =  Earth. distance(latitude,  longitude,  prevLat,  prevLon)/1 000.0; 

//  speed  is  in  km/hr. 

double  speed  =  distance/timeDiff  *  3600.0; 

_gh5KB.setFloatSlot(objltemLoc,  "speedRate",  new  Double(speed)); 

try  { 

_gh5KB.setCodeSlot(objlteml_oc,  "useCategoryCode",  "CEOFMA"); 

}  catch  ( InvalidCodeException  e  )  { 
throw  new  Error(e); 

} 

II  In  the  following,  100.0  is  arbitrary.  What  would  be  a  realistic 
//  accuracy  value  for  human  observation? 

_gh5KB.setFloatSlot(objltemLoc,  "accuracyQuantity",  new  Double(IOO.O)); 

} 

} 

3.7.  Class  COAAnalysisGUI 

The  decision  support  application  pops  up  certain  windows  automatically  or  by  user  request.  One  that  users  may  request  is  an  analysis 
of  a  course  of  action.  Class  COAAnalysisGUI  implements  a  user  interface  for  that  analysis.  A  course-of-action  analysis  is  displayed  in 
response  to  a  user  request  from  a  ThreatNotificationGUI. 

The  class  is  implemented  by  extending  JDialog.  The  implication  is  that  a  user  will  want  to  examine  an  analysis  before  continuing  to 
assess  the  consequences  of  a  threat  and  selecting  a  response, 
package  ida.bh.cro.friendlyorg; 

import  java. awt. Container; 
import  java.awt.Dimension; 
import  java. awt.event.ActionEvent; 
import  java. awt. event. ActionListener; 
import  java.awt.Font; 


C-53 


import  java.awt.Frame; 
import  java. util. Iterator; 
import  javax. swing.*; 

import  javax. swing. table.AbstractTableModel; 
import  ida.sd.pa.GUI; 

import  ida.bh.cro.friendlyorg. threat. response. CourseOfAction; 

I** 

*  The  <code>COAAnalysisGUI</code>  class  provides  the  user  interface  for  display  of  detailed  course  of  action  rationale  in  response  to  a  threat. 

*  The  GUI  presents  a  tabular  listing  of  the  steps  in  the  rationale  for  a  CoA. 

**/ 

class  COAAnalysisGUI 
extends  JDialog  { 

/**  The  {@link  ida.bh. agent. threat.response. CourseOfAction}  associated  with  this  instance.  */ 
private  CourseOfAction  _coa; 

jit* 

*  Constructs  a  <code>COAAnalysisGUI</code>,  which  is  a  user  interface  for  showing  the  rationale  behind  a  course  of  action.  Creates  and 

*  assembles  the  components  of  the  GUI  and  presents  them  to  the  user. 

*  @param  owner  The  dialog  that  owns  this  GUI. 

*  @param  coa  The  course  of  action  to  display. 

**  j 

public  COAAnalysisGUI(JDialog  owner,  CourseOfAction  coa)  { 
super(owner,  "Course  of  Action  Rationale"); 

_coa  =  coa; 

Container  contentPane  =  getContentPane(); 

contentPane.setLayout(new  BoxLayout(contentPane,  BoxLayout.Y_AXIS)); 
contentPane. add(GUI.VERTICAL_GAP); 

JLabel  stmt  =  new  JLabel(coa.description(),  SwingConstants. CENTER); 
stmt.setAlignmentX(0.5f); 

stmt.setFont(new  FontfSerif",  Font.BOLD,  (int)(getFont().getSize()*1 .25))); 

contentPane. add(stmt); 

contentPane. add(GUI.VERTICAL_GAP); 

JTable  coaTable  =  new  JTable(new  AbstractTableModel()  { 
public  int  getRowCount()  { 

return  _coa.getRationale().size(); 
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} 

public  int  getColumnCount()  { 

return  1; 

} 

public  Object  getValueAt(int  row,  int  column)  { 
return  _coa.getRationale().get(row); 

} 

}); 

coaTable.setRowSelectionAllowed(false); 

coaTable.setColumnSelectionAllowed(false); 

coaTable.setTableHeader(null); 

int  maxRationaleWidth  =  0; 

for  ( Iterator  rlter  =  _coa.getRationale().iterator();  rlter.hasNext();  )  { 

int  w  =  getFontMetrics(coaTable.getFont()).stringWidth((String)rlter.next()); 
if  (  w  >  maxRationaleWidth  ) 
maxRationaleWidth  =  w; 

} 

coaTable.setPreferredSize(new  Dimension(maxRationaleWidth,  coaTable.getPreferredSize(). height)); 

JScrollPane  coaTablePane  =  GUI.wrapTablelnScrollPane(coaTable,  "Rationale",  null); 

coaTablePane.setAlignmentX(0.5f); 

contentPane.add(coaTablePane); 

contentPane.add(GUI.VERTICAL_GAP); 

JButton  _close  =  new  JButton("OK"); 

_close.addActionListener(new  CloseDialog(this)); 

_close.setAlignmentX(0.5f); 

contentPane.add(_close); 

pack(); 

setVisible(true); 

} 

jit* 

*  The  <code>CloseDialog</code>  class  implements  Java's  {@link  java.awt.event.ActionListener  ActionListener}  interface  to 

*  allow  the  {@link  #_close}  button  to  close  the  dialog. 

**  i 

private  class  CloseDialog  implements  ActionListener  { 
private  JDialog  _dialog; 
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CloseDialog(JDialog  d)  { 

_dialog  =  d; 

} 

public  void  actionPerformed(ActionEvent  e)  { 

_dialog.dispose(); 

} 

} 

} 

3.8.  Class  ThreatExaminationGUI 

The  decision  support  application  pops  up  certain  windows  automatically  or  by  user  request.  Whenever  it  displays  a  threat,  a  user  may 
request  a  detailed  examination  of  that  threat.  Class  ThreatExaminationGUI  implements  a  user  interface  for  that  examination. 

package  ida.bh.cro.friendlyorg; 

import  java. awt. Container; 
import  java.awt.GridBagLayout; 

import  java. text. DecimalFormat; 

import  javax.  swing.  JFrame; 
import  javax. swing. JLabel; 
import  javax. swing. SwingConstants; 

import  ida.sd. Earth; 
import  ida.sd.gh5ontology.*; 
import  ida.sd.ontology.*; 
import  ida.sd. pa. GUI; 

I** 

*  The  <code>ThreatExaminationGUI</code>  class  displays  a  window  that  describes  a  threat.  The  primary  secrets  of  this  class  are  the 

*  information  presented  and  the  manner  in  which  it  is  presented. 

**  j 

public  class  ThreatExaminationGUI 
extends  JFrame  { 

jit* 

*  Creates  a  <code>ThreatExaminationGUI</code>  and  displays  it  to  the  user. 

*  @param  friendlyOrg  The  friendly  organisation  that  has  a  threat. 

*  @param  threatName  The  name  of  the  organisation  that  is  a  threat. 
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**  i 

public  ThreatExaminationGUI(FriendlyOrg  friendlyOrg,  String  threatName)  { 
super("Threat  Examination  of "  +  threatName); 

Container  contentPane  =  getContentPane(); 
contentPane.setLayout(new  GridBagLayout()); 

GH5KB  kb  =  friendlyOrg. getKB(); 

Instance  threat  =  kb.getObjectltem(threatName); 

String  value; 

GUI.addLabeledComponent(contentPane,  0,  "Name:",  new  JLabel(threatName,  SwingConstants.LEFT)); 

Instance  threatLocation  =  kb.getCurrentLocation(threat); 
if  ( threatLocation  !=  null )  { 

value  =  Earth. image(kb.getFloatSlot(threatLocation,  "latitudeCoordinate").doubleValue(), 
kb.getFloatSlot(threatLocation,  "longitudeCoordinate").doubleValue()); 

} 

else  { 

value  =  "(none  recorded)"; 

} 

GUI.addLabeledComponent(contentPane,  1,  "Location:",  new  JLabel(value,  SwingConstants.LEFT)); 

Instance  fo  =  friendlyOrg. getOrganisation(); 

Instance  foLocation  =  kb.getCurrentLocation(fo); 
if  ( foLocation  !=  null )  { 

try{ 

int  duration  =  kb.estimatedTimeToReach(threat,  foLocation). intValue(); 
if  (  duration  >=  86400  ) 
value  =  ">=  1  day"; 

else  { 

long  hrs  =  duration/3600; 
long  remSecs  =  duration%3600; 
long  mins  =  remSecs/60; 
long  secs  =  remSecs%60; 

DecimalFormat  twoD  =  new  DecimalFormat("00"); 

value  =  twoD.format(hrs)  +  +  twoD.format(mins)  +  +  twoD.format(secs); 

} 

}  catch  (  NoLocationException  e  )  { 
value  =  "(threat  location  unknown)"; 

}  catch  (  SpeedlndeterminateException  e  )  { 
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value  =  "(threat  speed  indeterminate)"; 

} 

} 

else  { 

value  =  "("  +  kb.getObjectltemName(friendlyOrg.getOrganisation())  +  "  location  unknown)"; 

} 

GUI.addLabeledComponent(contentPane,  2,  "Time  to  attack:",  new  JLabel(value,  SwingConstants.LEFT)); 
pack(); 

setVisible(true); 

} 

} 

3.9.  Class  ThreatNotificationGUI 

The  decision  support  application  pops  up  certain  windows  automatically  or  by  user  request.  It  automatically  displays  an  instance  of  the 
ThreatNotificationGUI  class  in  response  to  messages  it  receives  from  its  Threat  Notification  Agent. 

package  ida.bh.cro.friendlyorg; 

import  java.awt.Component; 
import  java. awt. Container; 
import  java.awt.Dimension; 
import  java. awt.event.ActionEvent; 
import  java. awt. event. ActionListener; 
import  java.awt.event.ltemEvent; 
import  java. awt. event. ItemListener; 
import  java.awt.Font; 
import  java.awt.lnsets; 

import  javax.  swing.  AbstractCellEditor; 
import  javax. swing. BorderFactory; 
import  javax. swing. border.TitledBorder; 
import  javax. swing. Box; 
import  javax. swing. BoxLayout; 
import  javax. swing. JButton; 
import  javax. swing. JCheckBox; 
import  javax. swing. JComponent; 
import  javax. swing. JDialog; 
import  javax. swing. JFrame; 
import  javax. swing. JLabel; 
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import  javax. swing. JOptionPane; 

import  javax. swing. JPanel; 

import  javax. swing. JScrollPane; 

import  javax. swing. JTable; 

import  javax. swing. ListSelectionModel; 

import  javax. swing. SwingConstants; 

import  javax. swing. table.AbstractTableModel; 

import  javax. swing. table. TableCellRenderer; 

import  javax. swing. table. TableCellEditor; 

import  javax. swing. table. TableColumn; 

import  javax. swing. table. TableColumnModel; 

import  ida.bh.cro.friendlyorg. threat. response. CourseOfAction; 

import  ida.bh.cro.friendlyorg. threat. response. ThreatResponseNotification; 

import  ida.sd. Diagnostics; 

import  ida.sd. adt.GUl.ButtonCellEditor; 

import  ida.sd. adt.Notifier; 

import  ida.sd. adt.OrganisationObserver; 

import  ida.sd.gh5ontology.GH5KB; 

import  ida.sd. pa. GUI; 

I** 

*  The  <code>ThreatNotificationGUI</code>  class  provides  the  user  interface  for  display  of  threat  notifications.  The  GUI  presents: 

*  <ul> 

*  <li>A  statement  of  the  threat.</li> 

*  <li>A  table  of  prioritized  candidate  courses  of  action. </li> 

*  <li>The  ability  to  analyze  a  course  of  action.  (The  analysis  is  to  examine  the  rationale  underlying  it.)</li> 

*  <li>The  ability  to  choose  a  course  of  action. </li> 

*  </ul> 

**  i 

class  ThreatNotificationGUI 
extends  JDialog  { 

/**  The  {@link  ida.bh. agent. threat. response. ThreatResponseNotification} 

*  being  shown  to  the  user.  */ 

private  ThreatResponseNotification  _trn; 

II  The  following  are  the  fields  of  this  dialog. 

/**  Lets  use  select  whether  to  show  all  courses  of  action,  or  only  those  with  non-zero  effectiveness.  */ 
private  JCheckBox_showlmpossibleCoAs  =  new  JCheckBox("Show  Impossible  Courses  of  Action"); 

/**  The  buttons  a  user  clicks  to  analyze  a  COA  in  detail.  */ 


C-59 


private  JButton[]  _selectionButtons; 

/**  The  table  that  holds  the  courses  of  action.  */ 
private  JTable  _coaTable; 

/**  Supplies  the  data  for  {@link  #_coaTable}.  */ 
private  COATableModel  _coaTableModel; 

/**  Never  set  {@link  #_coaTable}'s  height  to  show  more  than  this  number  of  rows. 

*  (Instead,  let  a  {@linkplain  #_tablePane  scroll  pane}  do  the  work.)  */ 
private  final  static  int  MAX  ROWS  =  10; 

/**  Keeps  {@link  #_coaTable}  to  a  fixed  maximum  size.  */ 
private  JScrollPane  _tablePane; 

/**  Font  for  title.  */ 

private  final  static  Font  TITLEFONT  =  new  Font("Serif",  Font.BOLD,  14); 

/**  Font  for  threat  statement.  */ 

private  final  static  Font  THREAT_STMT_FONT  =  new  Font("Serif",  Font.BOLD,  14); 
private  Notifier _ notifier; 

jit* 

*  Constructs  a  <code>ThreatNotificationGUI</code>  that  presents  a  {@link  ThreatResponseNotification}  to  the  user. 

*  @param  ownerFrame  The  frame  that  will  own  this  dialog. 

*  @param  org  The  {@link  FriendlyOrg}  presenting  this  dialog  to  a  user. 

*  @param  gh5kb  The  underlying  knowledge  base. 

*  @param  tr  The  {@link  ThreatResponseNotification}  to  be  shown  to  the  user. 

**  j 

public  ThreatNotificationGUI(JFrame  ownerFrame,  OrganisationObserver  org,  GH5KB  gh5kb,  ThreatResponseNotification  tr)  { 
super(ownerFrame,  gh5kb.getObjectltemName(org.getOrganisation())  +  Courses  of  Action"); 

_ notifier  =  new  Notifier(org); 

_trn  =  tr; 

int  nCoAs  =  _trn.size(); 

int  contentPanePreferredWidth  =  0; 

int  w; 

int  contentPanePreferredHeight  =  0; 

Container  contentPane  =  getContentPane(); 

contentPane.setLayout(new  BoxLayout(contentPane,  BoxLayout.Y_AXIS)); 
contentPane. add(GUI.VERTICAL_GAP); 
contentPanePreferredHeight +=  10; 

JLabel  windowTitle  =  new  JLabel(gh5kb.getObiectltemName(org.getOrganisation())  +  Threat  Response  Courses  of  Action", 

SwingConstants. CENTER); 
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windowTitle.setAlignmentX(0.5f); 

windowTitle.setFont(TITLE_FONT); 

contentPane.add(windowTitle); 

if  ( (w  =  windowTitle.getPreferredSize(). width)  >  contentPanePreferredWidth  ) 
contentPanePreferredWidth  =  w; 

contentPanePreferredHeight  +=  windowTitle.getPreferredSize().  height; 

JLabel  threatStmt  =  new  JLabel(tr.threatStatement(),  SwingConstants. CENTER); 

threatStmt.setAlignmentX(0.5f); 

threatStmt.setFont(THREAT_STMT_FONT); 

contentPane.add(threatStmt); 

contentPane.add(GUI.VERTICAL_GAP); 

if  ( (w  =  threatStmt.getPreferredSize(). width)  >  contentPanePreferredWidth  ) 
contentPanePreferredWidth  =  w; 

contentPanePreferredHeight  +=  threatStmt.getPreferredSize().  height  +  GUI.VERTICAL_GAP.getHeight(); 
if  (  nCoAs  ==  0  )  { 

contentPane.add(new  JLabel("No  available  courses  of  action!")); 
pack(); 

setVisible(true); 

return; 

} 

_selectionButtons  =  new  JButton[nCoAs]; 
for  ( int  i  =  0;  i  <  nCoAs;  i++  )  { 

JButton  b  =  new  JButton("View"); 

b.addActionListener(new  PopUpAnalysisGUI(this,  _trn.get(i))); 

_selectionButtons[i]  =  b; 

} 

_coaTable  =  new  JTable(_coaTableModel  =  new  COATableModel()); 

_coaTable.setRowSelectionAllowed(true);  //  Let  user  select  a  course  of  action. 

_coaTable.getSelectionModel().setSelectionMode(ListSelectionModel.SINGLE_SELECTION); 

_coaTable.setColumnSelectionAllowed(false); 

TableColumnModel  columnModel  =  _coaTable.getColumnModel(); 

columnModel.getColumn(0).setPreferredWidth(getFontMetrics(_coaTable.getFont()).stringWidth(_coiumnNames[0])  +  10); 
columnModel.  getColumn(1).setPreferredWidth(getFontMetrics(_coaTable.getFont()).stringWidth(_columnNames[1])  +  200); 

TableCellRenderer  buttonRenderer  =  new  TableCellRenderer()  { 

public  Component  getTableCellRendererComponent(  JTable  table, 

Object  value, 
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boolean  isSelected, 
boolean  hasFocus, 
int  row, 
int  column)  { 

return  _selectionButtons[row]; 

} 

}; 

TableColumn  buttonCol  =  _coaTable.getColumnModel().getColumn(_coaTableModel.getButtonColumn()); 
buttonCol.setCellRenderer(buttonRenderer); 

buttonCol. setPreferredWidth(_selectionButtons[0].getPreferredSize().width  +  1 0); 
buttonCol. setCellEditor(new  ButtonCellEditor()); 

GUI.setWidthProperties(columnModel.getColumn(0)); 

GUI.setWidthProperties(buttonCol); 

int  preferredTableWidth  =  0; 
for  ( int  i  =  0;  i  <  3;  i++  ) 

preferredTableWidth  +=  columnModel.getColumn(i).getPreferredWidth(); 

_coaTable.setPreferredSize(new  Dimension(preferredTableWidth,  coaTableHeight())); 

_tablePane  =  GUI.wrapTablelnScrollPane(_coaTable,  coaTableTitle(),  new  lnteger(MAX_ROWS  <  _trn.size()  ?  MAX  ROWS  :  _trn.size())); 

_tablePane.setAlignmentX(0.5f); 

contentPane.add(_tablePane); 

contentPane.add(GUI.VERTICAL_GAP); 

if  ( (w  =  _tablePane.getPreferredSize().width)  >  contentPanePreferredWidth  ) 
contentPanePreferredWidth  =  w; 

contentPanePreferredHeight  +=  _tablePane.getPreferredSize(). height  +  GUI.VERTICAL_GAP.getHeight(); 

_showlmpossibleCoAs.setHorizontalAlignment(SwingConstants. CENTER); 

_showlmpossibleCoAs.addltemListener(new  ltemListener()  { 

jit* 

*  Arranges  for  the  table  to  show/hide  "impossible"  courses-of-action  (those  with  zero  effectiveness).  Does  so  by: 

*  <ol> 

*  <li>Resetting  the  table's  preferred  size  based  on  the  number  of  rows  to  show.</li> 

*  <li>Firing  a  table-data-changed  event. </li> 

*  </ol> 

*  Also  resets  the  title  of  the  surrounding  scroll  pane. 

**  j 

public  void  itemStateChanged(ltemEvent  e)  { 

int  rowsToShow  =  (e.getStateChange()  ==  ItemEvent.SELECTED  ?_trn.size() :  _trn.possibleCoASize()); 
_coaTable.setPreferredSize(new  Dimension(_coaTable.getPreferredSize(). width,  _coaTable.getRowHeight()  *  rowsToShow)); 
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_coaTableModeI.fireTableDataChanged(); 

GUI.resetTitle(_tablePane,  coaTableTitle()); 

} 

}); 

contentPane.add(_showlmpossibleCoAs); 

if  ( (w  =  _showlmpossibleCoAs.getPreferredSize().width)  >  contentPanePreferredWidth  ) 
contentPanePreferredWidth  =  w; 

contentPanePreferredHeight  +=  _showlmpossibleCoAs.getPreferredSize(). height  +  GUI.VERTICAL_GAP.getHeight(); 

JButton  select  =  new  JButtonfSelect"); 

JButton  cancel  =  new  JButton("Cancel"); 
select.addActionListener(new  CloseButtonListener(this,  true)); 
cancel. addActionl_istener(new  CloseButtonListener(this,  false)); 

JPanel  selectButtonsPane  =  new  JPanel(); 
selectButtonsPane.setAlignmentX(0.5f); 

selectButtonsPane. setl_ayout(new  BoxLayout(selectButtonsPane,  BoxLayout.X_AXIS)); 
selectButtonsPane. add(Box.createHorizontalGlue()); 
selectButtonsPane. add(select); 

selectButtonsPane. add(Box.createRigidArea(new  Dimension^  0,  0))); 
selectButtonsPane. add(cancel); 
selectButtonsPane. add(Box.createHorizontalGlue()); 

selectButtonsPane. setPreferredSize(new  Dimension(  select.getPreferredSize().width  + 

10  + 

cancel. getPreferredSize().width, 
selectButtonsPane.  getPreferredSize().  height)); 

contentPane.add(selectButtonsPane); 

if  ( (w  =  selectButtonsPane.getPreferredSize(). width)  >  contentPanePreferredWidth  ) 
contentPanePreferredWidth  =  w; 

contentPanePreferredHeight  +=  selectButtonsPane. getPreferredSize(). height  +  GUI.VERTICAL_GAP.getHeight(); 

contentPane.setSize(new  Dimension(contentPanePreferred Width,  contentPanePreferredHeight)); 

pack(); 

setLocationRelativeTo(ownerFrame); 

setVisible(true); 

} 

I** 

*  Returns  a  string  that  provides  a  title  for  the  course-of-action  table.  The  purpose  is  to  standardize  the  title  throughout  this  module. 

*  @return  A  string  that  provides  a  title  for  the  course-of-action  table. 

**  j 
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private  String  coaTableTitle()  { 
int  maxSize  =  _trn.size(); 

int  currentSize  =  _showlmpossibleCoAs.isSelected()  ?  maxSize  :  _trn.possibleCoASize(); 
return  "Courses  of  Action  ("  +  currentSize  +  "  of "  +  maxSize  + 

} 

I** 

*  Returns  the  height  of  the  course-of-action  table.  This  value  varies  depending  on  whether  the  user  has  selected 

*  {@link_showlmpossibleCoAs}. 

*  @return  The  height  of  the  course-of-action  table,  in  pixels. 

**  j 

private  int  coaTableHeight()  { 

return  _coaTable.getRowHeight()  *  coaTableRows(); 

} 

I** 

*  Returns  the  number  of  rows  currently  available  for  display  in  thecourse-of-action  table.  This  value  varies  depending  on  whether  the 

*  user  has  selected  {@link_showlmpossibleCoAs}. 

*  @return  The  number  of  rows  in  the  course-of-action  table. 

**  j 

private  int  coaTableRows()  { 

return  _showlmpossibleCoAs.isSelected()  ?_trn.size() :  _trn.possibleCoASize(); 

} 

private  final  static  String[]  _columnNames  =  { "Rating",  "Course  of  Action", "" }; 
private  class  COATableModel  extends  AbstractTableModel  { 
private  final  static  int  VALUE  COL  =  0; 
private  final  static  int  DESCR  COL  =  1; 
private  final  static  int  BUTTON  COL  =  2; 

public  int  getRowCount()  { 

if  ( _showlmpossibleCoAs.isSelected() )  { 
return  _trn.size(); 

} 

else  { 

for  ( int  i  =  _trn.size()  - 1 ;  i  >=  0;  i —  )  { 
if  ( _trn.get(i).value()  >  0.0  ) 

return  i  +  1; 

} 

return  0; 

} 
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public  int  getColumnCount()  { 

return  3; 

} 

public  Object  getValueAt(int  row,  int  column)  { 
switch  (  column  )  { 
case  VALUECOL: 

return  new  Float(_trn.get(row).value()); 
case  DESCRCOL: 

return  _trn.get(row).description(); 
case  BUTTONCOL: 

return  _selectionButtons[row]; 
default: 

throw  new  Error("lmpossible  column  "  +  column); 

} 

} 

public  String  getColumnName(int  column)  { 
return  _columnNames[column]; 

} 

public  boolean  isCellEditable(int  row,  int  column)  { 
return  column  ==  BUTTON  COL; 

} 

public  Class  getColumnClass(int  column)  { 
switch  (  column  )  { 
case  VALUE  COL: 

return  Float.class; 
case  DESCR  COL: 

return  String. class; 
case  BUTTON  COL: 

return  JButton. class; 
default: 

throw  new  Error("lmpossible  column  "  +  column); 

} 

} 

public  int  getButtonColumn()  { 
return  BUTTON_COL; 
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} 

} 

I** 

*  The  <code>CloseButtonListener</code>  class  extends  {@link  java.awt.event.ActionListener} 

*  to  implement  functionality  needed  for  the  buttons  that  close  the  <code>ThreatNotificationGUI</code>. 

**  j 

private  class  CloseButtonListener  implements  ActionListener  { 
private  JDialog  _parent; 
private  boolean  JncludeSelection; 

I** 

*  Constructs  a  <code>CloseButtonListener</code>  that  specifieswhat  to  do  when  an  action  listener  receives  an  event.  The 

*  minimal  action  is  to  close  the  <code>ThreatNotificationGUI</code>. 

*  @param  d  The  {@link  javax.swing.JDialog}  containing  the  buttons  for  this  listener. 

*  @param  includeSelection  If  true,  the  observer  of  the  <code>ThreatNotificationGUI</code>  will  be  notified. 

*  If  false,  the  observer  will  not  be  notified. 

**  j 

CloseButtonListener(JDialog  d,  boolean  includeSelection)  { 

_parent  =  d; 

JncludeSelection  =  includeSelection; 

} 


j ** 

*  Callback  method  invoked  when  an  {@link  java.awt.event.ActionEvent}  occurs.  Uses  {@link  #_notifier}  to  signal  the  observer. 

*  If  {@link  #JncludeSelection}  is  true,  the  course  of  action  selected  by  the  user  is  included  in  the  signal.  In  any  case,  closes 

*  the  <code>ThreatNotificationGUI</code>. 

*  @param  e  The  {@link  java.awt.event.ActionEvent}. 

**  j 

public  void  actionPerformed(ActionEvent  e)  { 
if  ( JncludeSelection  )  { 

ListSelectionModel  Ism  =  _coaTable.getSelectionModel(); 
if  ( Ism.isSelectionEmptyO  )  { 

JOptionPane.showMessageDialog(  _parent, 

"Select  the  course  of  action  to  be  performed  (or  press  Cancel)", 

"Missing  Input", 

JOptionPane.ERRORJVIESSAGE); 

return; 

} 

_notifier.signal(new  Completed(Jrn,  Jrn.get(lsm.getMinSelectionlndex()))); 
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} 

else  { 

_notifier.signal(new  Completed(_trn)); 

} 

_parent.setVisible(false); 

} 

} 

private  class  PopUpAnalysisGUI  implements  ActionListener  { 
private  JDialog  _dialog; 
private  CourseOfAction  _coa; 

PopUpAnalysisGUI(JDialog  d,  CourseOfAction  coa)  { 

_dialog  =  d; 

_coa  =  coa; 

} 

public  void  actionPerformed(ActionEvent  e)  { 
new  COAAnalysisGUI(_dialog,  _coa); 

} 

} 

I** 

*  The  <code>Completed</code>  class  is  used  to  signal  that  a  <code>ThreatNotificationGUI</code>  has  completed.  An  instance 

*  contains  the  course  of  action  a  user  has  selected. 

**  i 

class  Completed  { 

private  CourseOfAction  _coa; 
private  ThreatResponseNotification  _trn; 

jit* 

*  Constructs  a  <code>Completed</code>  in  which  there  is  noassociated  {@link  ida.bh.agent.threat. response. CourseOfAction}. 

**  j 

Completed(ThreatResponseNotification  trn)  { 

_coa  =  null; 

_trn  =  trn ; 

} 

jit* 

*  Constructs  a  <code>Completed</code>  with  an  associated  {@link  ida.bh.agent.threat.response. CourseOfAction}. 

**  j 

Completed(ThreatResponseNotification  trn,  CourseOfAction  coa)  { 
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_coa  =  coa; 

_trn  =  trn; 

} 

jit* 

*  Returns  the  {@link  ida.bh.agent.threat. response. CourseOfAction}  associated  with  this  instance. 

*  @return  The  course  of  action  associated  with  this  instance,  or  null  if  no  course  of  action  was  associated  when  the  instance 

*  was  created. 

**  j 

CourseOfAction  getCourseOfAction()  { 
return  coa; 

} 

ThreatResponseNotification  getThreatResponseNotification()  { 
return  trn; 

} 

} 

} 

4.  Classes  in  Package  DBUpdate 
4.1.  Class  DBUpdateAgent 

The  DBUpdateAgent  class  implements  the  agent  a  Friendly  Organization  component  invokes  to  maintain  consistency  between  different 
Generic  Hub  data  sets  that  different  Friendly  Organization  components  use  in  the  course  of  a  simulation.  Each  Friendly  Organization 
component  has  one  of  these  agents.  They  send  updates  to  each  other. 

This  class  has  almost  the  minimum  functionality  of  an  agent.  It  registers  itself,  starts  an  IdleTask,  waits  until  that  task  tenninates,  then 
deregisters  itself  and  shuts  down. 

The  agent’s  constructor  takes  an  instance  of  OntologySQLBinding  as  a  parameter.  Through  this  instance,  the  agent  communicates  with 
the  RDBMS  accessing  the  relevant  Generic  Hub  data  set  for  this  Friendly  Organization  component. 

This  class  provides  one  method,  propagateChanges(),  that  other  classes  invoke.  It  initiates  the  sending  of  messages  that  communicate 
changes  to  other  Friendly  Organization  components. 

This  agent  uses  a  service  description  that  is  detailed  in  comparison  to  those  used  by  other  agents.  The  URL  of  the  underlying  RDBMS 
is  given  to  let  these  agents  determine  to  whom  changes  should  be  propagated.  Changes  are  only  sent  to  agents  that  access  other  Ge¬ 
neric  Hub  data  sets, 
package  ida.bh.cro.friendlyorg.dbupdate; 
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import  java. util. List; 

import  fipaos.agent.task.Task; 

import  fipaos.ont.fipa.fipaman.PropertyTemplate; 

import  fipaos.ont.fipa.fipaman.ServiceDescription; 

import  ida.sd. Diagnostics; 
import  ida.sd. FIPA.C4IAgent; 
import  ida.sd. osb.BindingException; 
import  ida.sd. osb.OntologySQLBinding; 

jit* 

*  The  <code>DBUpdateAgent</code>  class  provides  an  agent  that: 

*  <ol> 

*  <li>lnforms  other  <code>DBUpdateAgent</code>s  of  updates  to  the  DB.</li> 

*  <li>Listens  for  messages  from  other  <code>DBUpdateAgent</code>s  of  updates  to  the  DB,  and  performs  those  updates. </li> 

*  </ol> 

*  The  primary  secrets  of  this  class  are  the  algorithms  for  updating  the  DB,  and  the  algorithms  for  informing  other  agents  of  updates  to 

*  the  DB. 

**  j 

public  class  DBUpdateAgent 
extends  C4IAgent  { 

/**  The  registered  type  for  this  agent.  */ 

public  final  static  String  AGENT_TYPE  =  "db-upd"; 

/**  The  registered  name  of  the  ontology  for  this  agent.  */ 

public  final  static  String  DB  UPDATE  ONTOLOGY  =  "db-update"; 

/**  The  registered  name  of  the  language  this  agent  uses.  */ 
public  final  static  String  D B_U P D ATE  LAN G U AG E  =  "binary"; 

/**  The  property  name  in  this  agent's  service  description  stating  the  DB  URL  of  this  agent.  */ 
public  final  static  String  DB  URL  PROPERTY  =  "db-url"; 

/**  The  IdleTask  spawned  by  this  agent.  */ 
private  IdleTask  JdleTask; 

I** 

*  Constructs  a  <code>DBUpdateAgent</code>  instance  that  will  initiate  update  messages  to  other  agents,  and  will  respond  to  update 

*  messages  from  other  <code>DBUpdateAgent</code>s. 

*  @param  name  The  name  of  the  agent,  which  must  be  unique  across  the  platform. 

*  @param  dbUpdateAgentSearchlnterval  The  interval,  in  seconds,  between  searches  for  <code>DBUpdateAgent</code>s. 

*  @param  osb  A  specification  of  an  Ontology/SQL  binding. 

**  j 
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public  DBUpdateAgent(String  name,  Integer  dbllpdateAgentSearchlnterval,  OntologySQLBinding  osb)  { 
super(name); 

startPushing(); 

registerWithAMS(); 

try  { 

II  Register  with  the  local  DF,  giving  a  ServiceDescription  with  a  property  that  states  the  URL  of  the  database  we're  accessing. 
II  FIPA  00023  states  that  a  Service  Description  may  specify  languages,  but  fipa-os  doesn't  support  that. 

ServiceDescription  sd  =  new  ServiceDescription(); 
sd.setServiceType(AGENT_TYPE); 
sd.setProtocols(new  String[]  { "no-protocol" }); 
sd.setOntologies(new  String}]  {  DBUPDATEONTOLOGY  }); 

sd.setProperties(new  PropertyTemplatef]  {  new  PropertyTemplate(DB_URL_PROPERTY,  osb.getDBURL()) }); 
registerWithDF(sd); 

//  Define  an  IdleTask  that  will  act  as  the  Listener  task. 

setListenerTask(  JdleTask  =  new  ldleTask(dbUpdateAgentSearchlnterval,  osb) ); 

}  catch  (  Exception  e  )  { 

//  Possible  exceptions:  BindingException  and  fipaos.parser.ParserException. 

II  In  either  case,  we  stop  the  agent. 

Diagnostics. noteException(e,  this); 

Diagnostics. errorfStopping  DBUpdateAgent.",  this); 
shutdown(); 

} 

} 

jit* 

*  Stops  this  agent  and  all  tasks  it's  spawned. 

**  i 

public  void  stop()  { 

JdleTask. stop(); 
shutdown(); 

} 

I** 

*  Callback  method  invoked  when  {@link  IdleTask  IdleTask}  completes. 

**  i 

public  void  doneldleTask(Task  t)  { 

Diagnostics.fipaEvent("ldleTask  completed.",  this); 

} 
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I** 

*  Sends  a  message  to  other  DBUpdateAgents  that  a  change  to  the  DB  is  in  order. 

*  <p>The  message  consists  of  a  {@link  java. util. List}  of  SQL  queries. 

*  Each  query  is  either  an  <code>INSERT</code>  or  an  <code>UPDATE</code>. 

*  @param  queries  The  queries. 

**  j 

public  void  propagateChanges(List  queries)  { 

JdleTask.propagateChanges(queries); 

} 

} 

4.2.  Class  IdleTask 

The  IdleTask  class  listens  for  and  handles  database  updates.  Note  that  it  updates  a  Generic  Hub  data  set,  not  a  GH  knowledge  base.  The 
KnowledgeBaseRefreshTask  of  the  Tasks  agent  performs  that  chore. 

The  IdleTask  class  also  maintains  the  set  of  currently  known  DBUpdateAgents.  It  uses  this  set  to  determine  to  whom  updates  should  be 
sent. 

package  ida.bh.cro.friendlyorg.dbupdate; 

import  java. sql. Connection; 
import  java. sql. SQLException; 

import  java. util. HashSet; 
import  java. util. Iterator; 
import  java. util. LinkedList; 
import  java. util. List; 
import  java. util. Set; 

import  fipaos.ont.fipa.*; 

import  fipaos.ont.fipa.fipaman.AgentID; 

import  fipaos.ont.fipa.fipaman.DFAgentDescription; 

import  fipaos.ont.fipa.fipaman.PropertyTemplate; 

import  fipaos.ont.fipa.fipaman.ServiceDescription; 

import  fipaos. agent.*; 

import  fipaos. agent. conversation. Conversation; 
import  fipaos. agent.task.Task; 
import  fipaos. agent.task.WaitT ask; 

import  ida.sd. Diagnostics; 
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import  ida.sd.FIPA.AgentSearchTask; 
import  ida.sd.FIPA.notification.InformAgentsTask; 
import  ida.sd.osb.BindingException; 
import  ida.sd.osb.OntologySQLBinding; 
import  ida.sd.sql.sqIPA; 

I** 

*  The  <code>ldleTask</code>  class  implements  a  task  that  is  the  root  task  of  a  {@link  DBUpdateAgent}  instance.  Its  roles  are  to: 

*  <ol> 

*  <li>Respond  to  <code>INFORM</code>  messages  from  other  <code>DBUpdateAgent</code>s  by  updating  the  underlying  DB  based  on 

*  message  content. </li> 

*  <li>Periodically  search  for  other  <code>DBUpdateAgent</code>s  and  maintain  a  list  of  them.</li> 

*  <li>lmplement  the  <code>DBUpdateAgent</code>'s  ability  to  send  updates. </li> 

*  </ol> 

**  i 

public  class  IdleTask 
extends  Task  { 

/**  The  interval,  in  milliseconds,  between  the  times  when  the  ontology  is  searched  fordb  update  agents.  7 
private  final  int  _dbllpdateAgentSearchlnterval; 

/**  The  list  of  known  db  update  agents.  7 
private  Set_dbllpdateAgentlDs  =  new  HashSet(); 

/**  The  binding  to  an  SQL  DBMS.  7 
private  final  OntologySQLBinding  _osb; 
r  The  URL  of  the  underlying  DBMS.  7 
private  final  String  our  DB  URL; 

jit* 

*  Constructs  an  <code>ldleTask</code>  instance. 

*  @param  dbUpdateAgentSearchlnterval  The  interval,  in  seconds,  between  the  times  when  searches  fordb  update  agents  are  initiated. 

*  @param  osb  A  specification  of  an  Ontology/SQL  binding. 

*  @throws  BindingException  If  the  URL  of  the  DB  specified  in  <code>osb</code>  can't  be  determined. 

7 

public  ldleTask(lnteger  dbUpdateAgentSearchlnterval,  OntologySQLBinding  osb)  throws  BindingException  { 

_dbUpdateAgentSearch  Interval  =  dbUpdateAgentSearchlnterval.intValue()*1000; 

_osb  =  osb; 

_our_DB_URL  =  _osb.getDBURL(); 

} 

I** 
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*  Callback  method  invoked  when  FIPA-OS  successfully  initialises  the  <code>ldleTask</code>. 

*  Starts  a  task  to  search  for  other  {@link  DBUpdateAgent}s. 

**  i 

protected  void  startTask()  { 

Diagnostics.fipaEventfldleTask  started  OK.  Starting  DBUpdateAgent  search  task.",  this); 
newTask(  new  DBUpdateAgentSearchTask() ); 

} 

I** 

*  Callback  method  invoked  in  response  to  an  INFORM  request.  The  request  is  expected  to  be  a  list  of  queries. 

**  j 

public  void  handlelnform(Conversation  conv)  { 

Diagnostics. reportHandle(conv,  this); 

ACL  acl  =  conv.getACL(conv.getLatestMessagelndex()); 

if  ( !  acl.getOntology().equals(DBUpdateAgent.DB_UPDATE_ONTOLOGY) )  { 

Diagnostics. error("Unexpected  ontology  V"  +  acl.getOntology()  +  this); 

sendNotllnderstood(acl); 

return; 

} 

if  ( !  acl.getLanguage().equals(DBUpdateAgent.DB_UPDATE_LANGUAGE) )  { 

Diagnostics. error("Unexpected  language  V"  +  acl.getLanguage()  +  "V",  this); 
sendNotllnderstood(acl); 

return; 

} 

List  queries  =  (List)acl.getContentObject(); 

Diagnostics. domainEvent("Received  "  +  queries. size()  +  "  queries.",  this); 
for  ( Iterator  qlter  =  queries. iterator();  qlter.hasNext(); )  { 

String  qry  =  (String)qlter.next(); 

try  { 

Connection  dbConnection  =  _osb.getConnection(); 
synchronized  (  dbConnection  )  { 

sqlPA.executeUpdateQuery(dbConnection,  qry,  "DBUA_SP"); 

} 

}  catch  (  SQLException  e  )  { 

Diagnostics. noteException(e,  this); 

} 

} 

} 
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I** 

*  Sends  a  message  to  other  {@link  DBUpdateAgentjs  signaling  that  a  change  to  the  DB  is  in  order.  The  change  is  stated  as  a  list  of  SQL 

*  queries.  Starts  an  {@link  InformAgentsTask}. 

*  @param  queries  A  list  of  UPDATE  and  INSERT  queries. 

**  j 

public  void  propagateChanges(List  queries)  { 

newTask(  new  lnformAgentsTask(  new  LinkedList(_dbUpdateAgentlDs), 

(java.io.Serializable)queries, 

DBUpdateAgent.DB_UPDATE_ONTOLOGY, 

DBUpdateAgent.DB_UPDATE_LANGUAGE) ); 

} 

J ** 

*  Callback  method  invoked  when  the  {@link  InformAgentsTask}  completes. 

*  @param  t  The  completed  task. 

**  j 

public  void  donelnformAgentsTask(Task  t)  { 

Diagnostics.fipaEventflnformAgentsTask  done.",  this); 

} 

j ** 

*  Stops  this  task. 

*  @todo  Stop  all  subtasks. 

**  j 

public  void  stop()  { 
done(); 

} 

j ** 

*  Class  <code>DBUpdateAgentSearchTask</code>  performs  a  periodic  search  for  {@link  DBUpdateAgentjs.  It  maintains  a  set  of  those 

*  agents.  Excluded  from  the  set  are: 

*  <ol> 

*  <li>This  instance. </li> 

*  <li>Agents  whose  {@link  DBUpdateAgent#DB_URL_PROPERTY}  has  the  same  value  as  the  URL  of  the  DB  for  this  instance. </li> 

*  </ol> 

**  j 

public  class  DBUpdateAgentSearchTask  extends  Task  { 

j ** 

*  Callback  method  invoked  when  the  task  starts  successfully.  Starts  a  search  for  <code>DBUpdateAgent</code>s. 

**  j 
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protected  void  startTask()  { 

Diagnostics.fipaEvent("DBUpdateAgentSearchTask  started  OK.  Starting  search  for  agents.",  this); 
newTask(  new  AgentSearchTask(DBUpdateAgent.AGENT_TYPE) ); 

} 

I** 

*  Callback  method  invoked  with  the  agent  search  task  completes.  Adds  to  the  set  of  known  {@link  DBUpdateAgentjs  all  agents  not 

*  previously  known,  except  those  that  use  the  same  db  URL  as  this  instance.  It  then  starts  a  <code>WaitTask</code>  that,  on  completion, 

*  will  start  a  new  search. 

*  <p>This  method  does  not  account  for  the  possibility  of  a  <code>DBUpdateAgent</code>  terminating. 

*  @param  results  An  array  of  {@link  DFAgentDescription}  instances,  each  of  which  is  expected  to  be  a  <code>DBUpdateAgent</code> 

*  found  by  the  search. 

**  i 

public  void  doneAgentSearchTask(Object  results)  { 

Diagnostics.fipaEvent("AgentSearchTask  done.",  this); 

DFAgentDescription  descs[]  =  (DFAgentDescription  [])results; 

int  agentsAdded  =  0; 

synchronized  ( _dbUpdateAgentlDs  )  { 

DESCRIPTION:  for  ( int  i  =  0;  i  <  descs. length;  i++  )  { 

AgentID  id  =  descs[i].getAgentlD(); 

if  ( id.equals(_owner.getAID())  ||  _dbUpdateAgentlDs.contains(id) ) 

continue; 

Set  agentServices  =  descs[i].getAgentServices(); 

for  ( Iterator  aslter  =  agentServices. iterator();  aslter.hasNext();  )  { 

String  dbURL; 

try  { 

dbURL  =  dbURLProperty((ServiceDescription)aslter.next()); 

}  catch  (  Exception  e  )  { 

Diagnostics. error(id.getName()  +  "  +  e.getMessageQ,  this); 

continue  DESCRIPTION; 

} 

if  (  dbURL. equals(_our_DB_URL) ) 

continue; 

_dbUpdateAgentlDs.add(id); 

agentsAdded++; 

} 

} 

} 

Diagnostics.domainEvent("Added  "  +  agentsAdded  +  "  DB  Update  Agent(s)  to  known  set.",  this); 
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Diagnostics.fipaEvent("Starting  WaitTask.",  this); 
newTask(  new  WaitTask(_dbllpdateAgentSearchlnterval) ); 

} 

jit* 

*  Returns  the  {@link  #DB_URL_PROPERTY}  from  a  service  description. 

*  @param  serviceDescription  The  ServiceDescription  from  which  to  obtain  the  <code>DB_URL_PROPERTY</code>. 

*  @return  The  <code>DB_URL_PROPERTY</code>  from  a  service  description. 

*  @throws  Exception  If  the  service  description  doesn't  have  the  <code>DB_URL_PROPERTY</code>. 

**  j 

private  String  dbURLProperty(ServiceDescription  serviceDescription)  throws  Exception  { 

Set  properties  =  serviceDescription. getProperties(); 
if  (  properties  ==  null  ||  properties. size()  ==  0  ) 

throw  new  ExceptionfService  description  has  no  properties."); 
for  ( Iterator  plter  =  properties. iterator();  plter.hasNext();  )  { 

PropertyTemplate  p  =  (PropertyTemplate)plter.next(); 
if  (  p.getName().equals(DBUpdateAgent.DB_URL_PROPERTY) ) 
return  p.getTerm(); 

} 

throw  new  Exception("Service  description  lacks  "  +  DBUpdateAgent.DB_URL_PROPERTY  +  "  property."); 

} 

jit* 

*  Callback  method  invoked  when  a  {@link  WaitTask}  ends.  Starts  a  new  {@link  AgentSearchTask}  for  agents  of  type 

*  {@link  DBUpdateAgent#AGENT_TYPE  AGENT_TYPE}. 

*  @param  t  The  <code>WaitTask</code>  that  completed. 

**  j 

public  void  doneWaitTask(Task  t)  { 

Diagnostics.fipaEvent("WaitTask  done.  Starting  new  search  for  DBUpdateAgents.",  this); 
newTask(  new  AgentSearchTask(DBUpdateAgent.AGENT_TYPE) ); 

} 

} 

} 
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5.  Classes  in  Package  Threat. Perception 
5.1.  Class  ThreatPerceptionAgent 

The  ThreatPerceptionAgent  implements  a  FIPA-OS  agent  that  periodically  checks  for  the  presence  of  threats  in  the  battle  space  using 
facts  in  the  GH  knowledge  base.  Functionality  in  this  class  is  the  standard  agent  functionality:  register,  invoke  root  task,  wait  for  root 
task  tennination,  and  then  shut  down. 

The  class  includes  method  notifyOflndependentlyldentifiedThreat().  This  method  takes  a  battlefield  object  as  a  parameter.  Its  purpose  is  to 
simulate  the  same  actions  that  would  occur  if  the  ThreatPerceptionAgent  had  identified  that  object  as  a  threat.  It  was  developed  to  satisfy 
a  requirement  that  was  later  removed  from  the  implemented  version.  No  other  classes  in  the  IDA  prototype  simulation  invoke  it. 

package  ida.bh.cro.friendlyorg. threat. perception; 

import  fipaos.agent.task.Task; 

import  fipaos.ont.fipa.fipaman.ServiceDescription; 

import  ida.sd.adt.OrganisationObserver; 
import  ida.sd. Diagnostics; 
import  ida.sd. FIPA.C4IAgent; 
import  ida.sd.gh5ontology.GH5KB; 
import  ida.sd. ontology.*; 

I** 

*  The  <code>ThreatPerceptionAgent</code>  is  responsible  for  identifying  threats  to  an  organisation.  Threat  identification  involves  searches 

*  through  the  ontology  for  all  known  enemies,  and  checks  to  see  if  their  recent  position  indicates  movement  towards  an  organisation.  (This 

*  artificial  definition  of  a  threat  is  introduced  for  the  sake  of  the  example.  The  point  is  that  threat  identification  can  be  encapsulated  in  an  agent.) 

*  When  a  threat  is  found,  the  agent  notifies  all 

*  {@link  ida.bh.cro.friendlyorg. threat. response. ThreatResponseAgent  ThreatResponseAgent}</code>s. 

**  j 

public  class  ThreatPerceptionAgent 
extends  C4IAgent  { 

/**  The  root  task  for  this  agent.  7 
private  IdleTask  JdleTask; 

/**  The  string  that  identifies  the  agent  type  for  the  DF.  7 
public  final  static  String  AGENT_TYPE  =  "threat-perception"; 

private  Instance  _us; 
private  GH5KB  _gh5KB; 

jit* 
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*  Constructs  a  <code>ThreatPerceptionAgent</code>  that  will  assume  the  task  of  perceiving  threats  to  an  organisation. 

*  @param  agentName  The  name  of  the  agent.  Must  be  unique  across  the  platform. 

*  @param  organisationName  The  name  of  the  organisation  for  which  threats  are  to  be  perceived. 

*  @param  friendlyOrg  The  organisation  that  controls  this  threat  response  agent. 

*  @param  threatSearchlnterval  The  interval,  in  seconds,  between  times  when  threats  are  to  be  perceived. 

*  @param  threatResponseAgentSearchlnterval  The  interval,  in  seconds,  between  times  when  searches  for  response  agents  are  to  occur. 

*  @throws  UnknownOrgException  If  organisationName  does  not  refer  to  the  name  of  an  organisation  in  the  ontology. 

**  j 

public  ThreatPerceptionAgent(GH5KB  gh5KB, 

String  agentName, 

String  organisationName, 

OrganisationObserver  friendlyOrg, 

Integer  threatSearchlnterval, 

Integer  threatResponseAgentSearchlnterval)  { 

super(agentName); 

_gh5KB  =  gh5KB; 

_us  =  friendlyOrg. getOrganisation(); 
startPushing(); 

//  Register  with  the  local  AMS  (i.e.  the  platform)  as  the  first  action  our  agent  takes. 
registerWithAMS(); 

II  Now  we  can  register  with  the  local  DF. 

ServiceDescription  foService  =  new  ServiceDescription(); 
foService.setServiceName(agentName); 
foService. setServiceType(AGENT_TYPE); 
registerWithDF(foService); 

//  Make  an  IdleTask  responsible  for  listening  to  all  incoming  messages. 

setListenerTask(_idleTask  =  new  ldleTask(_gh5KB,  friendlyOrg,  threatSearchlnterval,  threatResponseAgentSearchlnterval)); 

} 

I** 

*  Simulates  the  behavior  of  a  threat  to  us  being  perceived.  Creates  an  {@link  InformThreatResponseAgentsTask},  informing  all  threat 

*  response  agents  known  to  the  {@link  IdleTask}. <p>This  method  may  be  invoked  when  a  threat  is  identified  by  a  source  other  than  the 

*  <code>ThreatPerceptionAgent</code>,  which  is  periodic.  The  intent  is  to  allow  for  non-periodic  identification  of  threats. 

*  @param  objltem  The  battlefield  object  that  is  perceived  to  be  a  threat. 

*  @todo  Add  a  corresponding  method  to  cancel  a  threat. 

**  j 

public  void  notifyOflndependentlyldentifiedThreat(lnstance  objltem)  { 
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if  (  obj Item. instanceOf(  gh5KB.getCls("Orqanisation")) ) 

_tm.newTask(  new  lnformThreatResponseAgentsTask(_gh5KB,  JdleTask.getKnownThreatResponseAgents(),  objltem,_us,  true) ); 

else 

Diagnostics. error("Not  prepared  to  handle  "  +  objltem.getDirectType().getName(),  this); 

} 

jit* 

*  Callback  method  invoked  when  an  {@link  InformThreatResponseAgentsTask}  completes.  Does  nothing. 

**  j 

public  void  donelnformThreatResponseAgentsTask(Task  t)  { 

Diagnostics.fipaEvent("Aperiodic  InformThreatResponseAgentsTask  completed.",  this); 

} 

I** 

*  Stops  this  agent  and  its  tasks.  7 

public  void  stop()  { 
shutdown(); 

} 

} 

5.2.  Class  IdleTask 

The  IdleTask  class  of  the  threat  perception  agent  encapsulates  the  functionality  that  identifies  a  threat.  In  other  words,  the  meaning  of 
“threat”  is  in  this  class.  It  is  specifically  supplied  by  the  private  method  searchForTheatsAndNotifyOfAny(),  which  is  part  of  the  subtask 
OntologySearchTask.  A  more  descriptive  name  should  be  given  to  this  method  to  facilitate  its  use. 

The  IdleTask  class  also  maintains  the  current  set  of  active  threat  response  agents.  The  searchForTheatsAndNotifyOfAny()  method  uses  this 
set  each  time  it  finds  a  threat.  The  actual  notification  is  performed  by  an  instance  of  the  InformThreatResponseAgentsTask  class,  which  is 
started  as  a  subtask  of  OntologySearchTask. 

package  ida.bh.cro.friendlyorg. threat. perception; 

import  java. util. Iterator; 
import  java. util. LinkedList; 
import  java. util. List; 
import  java. util. Set; 

II  Import  the  fipa  classes 
import  fipaos.ont.fipa.*; 

II  Import  the  classes  for  DF  searches 

import  fipaos.ont.fipa.fipaman.DFAgentDescription; 
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//  We  will  also  need  to  import  agent  classes 
import  fipaos. agent.*; 
import  fipaos. agent.task.Task; 
import  fipaos. agent.task.WaitT ask; 

import  ida.sd.adt.Notifier; 

import  ida.sd.adt.OrganisationObserver; 

import  ida.sd. Diagnostics; 

import  ida.sd. FIPA.AgentSearchTask; 

import  ida.sd. FIPA. notification. InformAgentsTask; 

import  ida.sd.gh5ontology.*; 

import  ida.sd. ontology.*; 

jit* 

*  The  <code>ldleTask</code>  class  implements  a  task  that  is  the  root  task  of  a  ThreatPerceptionAgent  instance.  Its  roles  are  to: 

*  <ol> 

*  <li>Periodically  examine  the  ontology  for  hostile  organisations  and,  for  each  such  organisation,  identify  all  that  are  perceived  to  be 

*  a  threat.</li> 

*  <li>Notify  all  ThreatResponseAgents  of  all  threats. </li> 

*  </ol> 

*  The  primary  secrets  of  this  class  are  the  algorithms  for  carrying  out  the  required  functionality. 

**  j 

public  class  IdleTask 
extends  Task  { 

private  GH5KB  _gh5KB; 

/**  The  organisation  that  is  the  focus  of  concern.  7 
private  Instance  _concernedOrganisation; 

/**  The  interval,  in  milliseconds,  between  the  times  when  the  ontology  is  searched  for  threats.  7 
private  int  _threatSearchlnterval; 

private  int  _threatResponseAgentSearchlnterval; 

/**  The  set  of  enemy  agents  known  to  present  a  threat.  7 
private  Set_threateningOrganisations  =  new  java. util. HashSet(); 

/**  The  list  of  known  threat  response  agents.  7 

private  List_knownThreatResponseAgentlDs  =  new  LinkedList(); 

private  Notifier _ notifier; 

jit* 
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*  Constructs  an  <code>ldleTask</code>  instance. 

*  @param  organisation  The  organisation  that  is  the  focus  of  concern;  that  is,  we  determine  whether  something  threatens 

*  this  particular  organisation. 

*  @param  threatSearchlnterval  The  interval,  in  seconds,  between  the  times  when  searches  for  threats  are  initiated. 

*  @param  threatResponseAgentSearchlnterval  The  interval,  in  seconds,  between  the  times  when  searches  for  threat  response  agents 

*  are  initiated. 

*/ 

public  ldleTask(GH5KB  gh5KB, 

OrganisationObserver  organisation, 

Integer  threatSearchlnterval, 

Integer  threatResponseAgentSearchlnterval)  { 

_gh5KB = gh5KB; 

_concernedOrganisation  =  organisation. getOrganisation(); 

_threatSearchlnterval  =  threatSearchlnterval. intValue()*1 000; 

_threatResponseAgentSearchlnterval  =  threatResponseAgentSearchlnterval.intValue()*1 000; 

_notifier  =  new  Notifier(organisation); 

} 

jit* 

*  Callback  method  invoked  when  FIPA-OS  successfully  initialises  the  <code>ldleTask</code>.  Starts  two  tasks: 

*  <ol> 

*  <li>A  task  to  search  for  threat  response  agents. </li> 

*  <li>A  task  to  search  the  ontology  for  threats. </li> 

*  </ol> 

**  j 

protected  void  startTask()  { 

Diagnostics.fipaEventfldleTask  started  OK.  Starting  tasks.",  this); 

newTask(  new  OntologySearchTask() ); 

newTask(  new  ThreatResponseAgentSearchTask() ); 

} 

jit* 

*  The  <code>OntologySearchTask</code>  class  periodically  searches  the  ontology  for  organisations  that  are  threats,  or  were  but  are  no 

*  longer.  Whenever  it  finds  such  an  organisation,  it  notifies  all  known  threat  response  agents. 

**  j 

public  class  OntologySearchTask  extends  Task  { 

/**  The  number  of  threats  about  which  this  task  is  currently  sending  notifications.  */ 
private  Integer  notifications  =  new  Integer(O); 

j ** 
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*  Callback  method  invoked  when  the  task  starts  successfully.  Starts  a  search  for  threats. 

**  i 

protected  void  startTask()  { 

searchForThreatsAndNotifyOfAny(); 

} 

I** 

*  Searches  the  knowledge  base  for  anything  that  looks  like  a  threat.  Also  searches  for  things  that  were  threats,  but  aren't  now. 

*  Sends  a  message  of  each  threat  and  non-threat  to  every  known  {@link  ida.bh.agent.threat.response.ThreatResponseAgent}. 

**  i 

private  void  searchForThreatsAndNotifyOfAny()  { 

CIs  orgCIs  =  _gh5KB.getCls("Organisation"); 

for  ( Iterator  instlter  =  _gh5KB.getBattlefieldObjects().iterator();  instlter.hasNext();  )  { 

Instance  candidate  =  (lnstance)instlter.next(); 

II  Only  consider  organisations. 

CIs  candidateType  =  candidate. getDirectType(); 

if  ( !  (candidateType. equals(orgCls)  ||  candidateType. hasSuperclass(orgCls)) ) 

continue; 

boolean  isInPathOfCandidate; 

try  { 

isInPathOfCandidate  =  _gh5KB.inPathOf(candidate,  _concernedOrganisation); 

}  catch  (  NoLocationException  e  )  { 

continue; 

}  catch  (  SpeedlndeterminateException  e  )  { 

continue; 

} 

if  ( isInPathOfCandidate  )  { 

StringBuffer  msg  =  new  StringBuffer() 

.append(_gh5KB.getStringSlot(candidate,  "name")) 

.appendf  is  moving  toward  ") 

,append(  gh5KB.getStringSlot(  concernedOrganisation,  "name")); 

if  ( _threateningOrganisations.contains(candidate) )  { 

Diagnostics. domainEvent(msg. appendf  (previously  detected)"). toString(),  this); 

continue; 

} 

Diagnostics. domainEvent(msg. appendf  (new  threat)"). toString(),  this); 

_threateningOrganisations.add(candidate); 
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_notifier.signal(new  ThreatPerception(true,  candidate)); 
synchronized(  _knownThreatResponseAgentlDs  )  { 

newTask(  new  lnformThreatResponseAgentsTask(_gh5KB, 

_knownThreatResponseAgentlDs, 

candidate, 

_concernedOrganisation,  true) 

); 

} 

incrementNotificationCount(); 

} 

else  { 

if  ( _threateningOrganisations.contains(candidate) )  { 

Diagnostics. domainEvent(_gh5KB.getStringSlot(candidate,  "name")  +  "  is  no  longer  a  threat",  this); 
_threateningOrganisations.remove(candidate); 

_notifier.signal(new  ThreatPerception(false,  candidate)); 
synchronized(  _knownThreatResponseAgentlDs  )  { 

newTask(  new  lnformThreatResponseAgentsTask(  _gh5KB, 

_knownThreatResponseAgentlDs, 

candidate, 

_concernedOrganisation, 

false) 

); 

} 

incrementNotificationCount(); 

} 

} 

} 


//  If  no  threats  were  found,  wait  for  an  interval,  then  search  again. 
synchronized(  notifications  )  { 
if  ( notifications. intValue()  ==  0  )  { 

Diagnostics. domainEvent("No  threats  found.  Starting  WaitTask.",  this); 
newTask(  new  WaitTask(_threatSearchlnterval) ); 

} 

} 

} 


jit* 

*  Callback  method  invoked  when  a  {@link  InformThreatResponseAgentsTask}  ends. 

*  When  all  have  ended,  wait  for  an  interval  before  searching  again. 
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**  i 

public  void  donelnformThreatResponseAgentsTask(Task  t)  { 

Diagnostics.fipaEvent("lnformThreatResponseAgentsTask  completed.",  this); 
synchronized(  notifications  )  { 
int  notifications; 

notifications  =  notifications. intValue()  - 1; 
notifications  =  new  Integer(notifications); 
if  (  notifications  ==  0  )  { 

Diagnostics. domainEvent("AII  threat  response  agents  informed.  Starting  WaitTask.",  this); 
newTask(  new  WaitTask(_threatSearchlnterval) ); 

} 

} 

} 

jit* 

*  Callback  method  invoked  when  a  <code>WaitTask</code>  ends.  Starts  a  new  search  of  the  ontology  for  threats. 

**  j 

public  void  doneWaitTask(Task  t)  { 

Diagnostics.fipaEvent("WaitTask  done.  Starting  new  search  for  threats.",  this); 
searchForThreatsAndNotifyOfAny(); 

} 

jit* 

*  Safely  increments  the  notifications  count. 

**  j 

private  void  incrementNotificationCount()  { 
synchronized  ( notifications  )  { 

notifications  =  new  lnteger(_notifications.intValue()  +  1); 

} 

} 

} 

j ** 

*  The  <code>ThreatResponseAgentSearchTask</code>  class  periodically  searches  for  all  threat  response  agents.  Its  responsibility  is  to 

*  update  the  <code>_knownThreatResponseAgentlDs</code>  field. 

**  j 

public  class  ThreatResponseAgentSearchTask  extends  Task  { 

protected  void  startTask()  { 

Diagnostics.fipaEvent("ThreatResponseAgentSearchTask  started  OK.  Starting  search  for  agents.",  this); 
newTask(  new  AgentSearchTask("threat-response") ); 
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} 

public  void  doneAgentSearchTask(Object  results)  { 

Diagnostics.fipaEvent("AgentSearchTask  done.",  this); 

DFAgentDescription  descs[]  =  (DFAgentDescription  [])results; 

Diagnostics. domainEventfFound  "  +  descs. length  +  "  threat-response  agent(s).",  this); 
synchronized  ( _knownThreatResponseAgentlDs  )  { 

_knownThreatResponseAgentlDs.clear(); 
for  ( int  i  =  0;  i  <  descs. length;  i++  ) 

_knownThreatResponseAgentlDs.add(descs[i].getAgentlD()); 

} 

Diagnostics.fipaEvent("Starting  WaitTask.",  this); 

newTask(  new  WaitTask(_threatResponseAgentSearchlnterval) ); 

} 

public  void  doneWaitTask(Task  t)  { 

Diagnostics.fipaEvent("WaitTask  done.  Starting  new  search  for  agents.",  this); 
newTask(  new  AgentSearchTask("threat-response") ); 

} 

} 

I** 

*  Returns  the  list  of  currently  known  threat  response  agent  IDs. 

*  @return  The  list  of  currently  known  threat  response  agent  IDs. 

**  j 

public  List  getKnownThreatResponseAgents()  { 
return  _knownThreatResponseAgentlDs; 

} 

} 

5.3.  Class  InformThreatResponseAgentsTask 

The  InformThreatResponseAgentsTask  class  carries  out  the  basic  function  of  sending  threat  messages  to  a  given  list  of  agents.  The 
class’s  constructor  is  given  a  subject/object  pair  (each  is  a  battlefield  object).  It  formulates  an  SLO  message  from  this  information,  and 
passes  that  message  to  the  generic  InformAgentsTask  class. 

package  ida.bh.cro.friendlyorg. threat. perception; 

import  java. util. LinkedList; 
import  java. util. List; 

//  Import  the  fipa  classes 
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import  fipaos.ont.fipa.*; 

//  We  will  also  need  to  Import  agent  classes 
import  fipaos. agent.*; 
import  fipaos. agent.task.Task; 

import  ida.sd. Diagnostics; 

import  ida.sd. FIPA.notification.InformAgentsTask; 

import  ida.sd. FIPA.slO.SLO; 

import  ida.sd. FIPA.slO.SLOParser; 

import  ida.sd.gh5ontology.*; 

import  ida.sd.ontology. Instance; 

jit* 

*  The  <code>lnformThreatResponseAgentsTask</code>  class  implements  a  task  whose  role  is  to  inform 

*  {@link  ida.bh.cro.friendlyorg.threat.response.ThreatResponseAgentjs  of  a  threat.  The  primary  secret  of  this  class  is  the  algorithms  for 

*  informing  threat  response  agents. 

**  i 

public  class  InformThreatResponseAgentsTask 
extends  Task  { 

private  final  GH5KB  _gh5KB; 
private  final  List  agentIDs; 
private  final  Instance  subject; 
private  final  Instance  object; 
private  final  boolean  JsThreat; 

jit* 

*  Creates  an  <code>lnformThreatResponseAgentsTask</code>  instance  that  encapsulates  a  list  of  agents  to  inform,  and  threat  information  of 

*  which  to  inform  them. 

*  @param  threatResponseAgentIDs  The  list  of  {@link  ida.bh.cro.friendlyorg.threat.response.ThreatResponseAgentjs 

*  that  this  task  shall  inform. 

*  @param  subject  The  organisation  {@link  ida.sd.ontology. Instance}  that  is  (not)  a  threat. 

*  @param  object  The  organisation  {@link  ida.sd. ontology. Instance}  that  is  (not)  threatened. 

*  @param  isThreat  True  if  <code>subject</code>  threatens 

*  <code>object</code>,  false  if  not. 

**  i 

public  lnformThreatResponseAgentsTask(GH5KB  gh5KB,  List  threatResponseAgentIDs,  Instance  subject,  Instance  object,  boolean  isThreat)  { 
_gh5KB  =  gh5KB; 

_agentlDs  =  threatResponseAgentIDs; 

_subject  =  subject; 
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_object  =  object; 

JsThreat  =  isThreat; 

} 

I** 

*  Callback  method  invoked  by  FIPA-OS  when  this  task  has  initialized  successfully.  Formulates  the  threat  statement  and  creates  an 

*  {@link  ida.sd.FIPA.notification.InformAgentsTask}  to  carry  out  the  notification. 

**  j 

protected  void  startTask()  { 

List  predicateTerms  =  new  LinkedList(); 

predicateTerms.add(new  SL0.Strnq(  gh5KB.getStringSlot(  subject,  "name"))); 
predicateTerms. add(new  SL0.Strnq(  gh5KB.getStringSlot(  object,  "name"))); 

try  { 

II  When  I  implement  SL1,  I'll  change  this  to  (threat ...)  or  (not  (threat ...)). 

SLO.AtomicFormula  threatStmt  =  new  SLO.PredicateAtomicFormula(_isThreat  ?  "threat" :  "not-threat",  predicateTerms); 
newTask(  new  lnformAgentsTask(_agentlDs, "("  +  threatStmt.toString()  +  ")",  "threat",  SLOParser.getLanguage()) ); 

}  catch  (  SLO.InvalidContentException  e  )  { 

throw  new  Error(e);  //  Shouldn't  happen,  as  we  construct  the  stmt  identically  each  time. 

} 

} 

I** 

*  Callback  method  invoked  when  the  {@link  ida.sd.FIPA. notification. InformAgentsTask}  ends.  Ends  this  task,  notifying  its  parent. 

*  @param  t  The  <code>lnformAgentsTask</code>  that  has  completed. 

**  j 

public  void  donelnformAgentsTask(Task  t)  { 

Diagnostics.fipaEvent("lnformAgentsTask  completed.",  this); 
done(); 

} 

} 

5.4.  Class  ThreatPerception 

The  ThreatPerception  class  is  a  simple  data  abstraction.  Its  constructor  takes  an  instance  (from  the  knowledge  base)  of  a  battlefield  ob 
ject,  plus  a  Boolean  statement  of  whether  that  object  currently  poses  a  threat.  Its  methods  allow  read-only  access  to  the  constructor’ 
parameters.  It  is  used  to  communicate  threat  information  among  the  packages  and  subpackages  of  the  Friendly  Organization  compo 
nents. 

package  ida.bh.cro.friendlyorg. threat. perception; 
import  ida.sd. ontology. Instance; 
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public  class  ThreatPerception  { 
private  boolean  JsThreat; 
private  Instance  _org; 

public  ThreatPerception(boolean  isThreat,  Instance  org)  { 

JsThreat  =  isThreat; 

_org  =  org; 

} 

public  boolean  getlsThreatened()  { 
return  JsThreat; 

} 

public  Instance  getOrganisation()  { 
return  _org; 

} 

} 

6.  Classes  in  Package  Threat. Response 
6.1.  Class  ThreatResponseAgent 

The  ThreatResponseAgent  class  implements  a  FIPA-OS  agent  that  formulates  courses  of  action  in  response  to  threats  detected  by  the 
threat  perception  agent.  No  code  to  shut  down  the  agent  cleanly  was  implemented  in  the  IDA  prototype,  but  should  be  added  in  a  pro¬ 
duction-level  implementation. 

package  ida.bh.cro.friendlyorg. threat. response; 

import  fipaos.ont.fipa.fipaman.ServiceDescription; 

import  ida.sd.adt.OrganisationObserver; 
import  ida.sd.FIPA.C4IAgent; 
import  ida.sd.gh5ontology.GH5KB; 

I** 

*  The  <code>ThreatResponseAgent</code>  class  is  responsible  for  responding  to  threat  information  messages.  The  primary  secrets  of  the  class 

*  are  the  algorithms  and  data  structures  for  responding  to  those  messages. 

**  i 

public  class  ThreatResponseAgent 
extends  C4IAgent  { 

/**  The  type  of  agent  we  use  when  registering  with  the  DF.  7 
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public  final  static  String  AGENT  TYPE  =  "threat-response"; 

jit* 

*  Constructs  a  <code>ThreatResponseAgent</code>  that  will  begin  listening  for  detected  threats  and  formulating  responses. 

*  @param  gh5KB  The  knowledge  base  the  agent  is  to  use. 

*  @param  agentName  The  name  to  use  for  the  agent.  Must  be  unique  across  the  platform. 

*  @param  organisationObserver  An  observer  that  will  be  notified  of  the  threat  responses. 

**  j 

public  ThreatResponseAgent(GH5KB  gh5KB,  String  agentName,  OrganisationObserver  organisationObserver)  { 
super(agentName); 

startPushing(); 

II  Register  with  the  local  AMS  (i.e.  the  platform)  as  the 

//  first  action  our  agent  takes. 

registerWithAMS(); 

//  Now  we  can  register  with  the  local  DF. 

ServiceDescription  foService  =  new  ServiceDescription(); 
foService.setServiceName(agentName); 
foService. setServiceType(AGENT_TYPE); 
registerWithDF(foService); 

//  Make  an  IdleTask  responsible  for  listening  to  all  incoming  messages. 
setListenerTask(new  ldleTask(gh5KB,  organisationObserver)); 

} 

} 

6.2.  Class  IdleTask 

The  IdleTask  class,  the  root  task  of  a  threat  response  agent,  listens  for  messages  from  a  threat  perception  agent.  These  messages  are 
sent  in  SLO,  with  the  INFORM  perfonnative.  The  handlelnformQ  method  receives  and  parses  each  message  to  yield  SLO  content.  It  then 
evaluates  the  content  using  an  instance  of  ThreatStmtContext  (see  Section  6.10)  as  the  context.  Callback  methods  in  the  IdleTask  class 
(respondToThreat()  and  respondToThreatCancellation())  link  the  context  with  the  IdleTask,  enabling  the  IdleTask  to  notify  the 
FriendlyOrganisation  instance  that  launched  the  threat  response  agent. 

package  ida.bh.cro.friendlyorg. threat. response; 

import  java. util. Collection; 
import  java. util. Collections; 
import  java. util. Iterator; 
import  java. util. LinkedList; 


C-89 


import  java. util. List; 
import  java. util. Map; 
import  java. util. Set; 

II  Import  the  fipa  classes 
import  fipaos.ont.fipa.*; 

//  Import  the  classes  for  DF  searches 

import  fipaos.ont.fipa.fipaman.DFAgentDescription; 

II  We  will  also  need  to  import  agent  classes 
import  fipaos. agent.*; 
import  fipaos. agent.task.Task; 
import  fipaos. agent.task.WaitT ask; 

import  fipaos. agent. conversation. Conversation; 

import  ida.sd.adt.Notifier; 

import  ida.sd.adt.OrganisationObserver; 

import  ida.sd. Diagnostics; 

import  ida.sd. FIPA. AgentSearchTask; 

import  ida.sd. FIPA.notification.InformAgentsTask; 

import  ida.sd. FIPA. slO.ParseException; 

import  ida.sd. FIPA. slO.SLO; 

import  ida.sd. FIPA.slO.SLOParser; 

import  ida.sd.gh5ontology.GH5KB; 

import  ida.sd.ontology.CIs; 

import  ida.sd.ontology. Instance; 

jit* 

*  The  <code>ldleTask</code>  class  implements  a  task  that  is  the  root  task  of  a  <code>ThreatResponseAgent</code>  instance.  Its  role  is  to 

*  listen  for  threat  perceptions.  When  it  receives  one,  it  formulates  a  response  and  notifies  the  associated  organisation  of  that  response. 

**  i 

public  class  IdleTask 
extends  Task  { 

/**  An  instance  of  the  {@link  ida.sd.adt.Notifier  Notifier}  class.  Used  for  notification.  */ 
private  final  Notifier _ notifier; 

/**  The  organisation  associated  with  the  observer  that  is  to  be  notified  in  response  to  threats.  */ 
private  final  Instance  organisation; 

private  final  GH5KB  _gh5KB; 
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I** 

*  Constructs  an  <code>ldleTask</code>  instance. 

*  @param  organisation  The  Observer  to  be  notified  of  our  response  to  threats. 

*/ 

public  ldleTask(GH5KB  gh5KB,  OrganisationObserver  organisation)  { 

_gh5KB  =  gh5KB; 

_ notifier  =  new  Notifier(organisation); 

-Organisation  =  organisation.getOrganisation(); 

} 

I** 

*  Callback  method  invoked  when  FIPA-OS  successfully  initialises  the  <code>ldleTask</code>. 

**  i 

protected  void  startTask()  { 

Diagnostics.fipaEvent("ldleTask  started  OK.",  this); 

} 

I** 

*  Callback  method  invoked  when  an  INFORM  request  is  received.  Receives  and  interprets  the  request,  which  should  be  threat  information. 

*  @param  conv  The  {@link  fipaos.agent.conversation. Conversation  Conversation}  containing  the  INFORM  request. 

**  j 

public  void  handlelnform(Conversation  conv)  { 

Diagnostics. reportHandle(conv,  this); 

ACL  acl  =  conv.getACL(conv.getLatestMessagelndex()); 

if  (  !  (acl.getOntology().equals("threat")  &&  acl.getLanguage().equals(SLOParser.getLanguage())) )  { 

Diagnostics. errorfllnexpected  ACL  "  +  new  String(fipaos.parser.acl.string.Parser.deparse(acl)),  this); 
sendNotUnderstood(acl); 

return; 

} 

try  { 

SLO. Content  threatFact  =  SLOParser.parseContent(acl.getContentObject().toString()); 

Diagnostics. domainEvent("Received  threat  stmt "  +  threatFact.toString(),  this); 
threatFact.evaluate(new  ThreatStmtContext(acl,  this)); 

}  catch  (  ParseException  e  )  { 

Diagnostics. noteException(e,  this); 

sendNotUnderstood(acl); 

return; 

}  catch  (  SLO.EvaluationException  e  )  { 

Diagnostics. noteException(e,  this); 
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sendNotllnderstood(acl); 

return; 

} 

} 

I** 

*  Callback  method  invoked  through  {@link  ThreatStmtContext}  in  response  to  a  message  noting  a  newly  preceived  threat  (not  necessarily  to 

*  us).  We  formulate  and  prioritize  responses,  then  signal  our  controlling  organisation  of  those  responses. 

*  @param  threateningOrganisationName  The  name  of  the  organisation  that's  threatening  <code>threatenedOrganisationName</code>. 

*  @param  threatenedOrganisationName  The  name  of  the  organisation  that's  threatened  by  <code>threateningOrganisationName</code>. 

**  j 

void  respondToThreat(String  threateningOrganisationName,  String  threatenedOrganisationName)  { 

Diagnostics. domainEvent("Responding  to  threat  of "  +  threateningOrganisationName  +  "  to  "  +  threatenedOrganisationName,  this); 

CIs  orgCIs  =  _gh5KB.getCls("Organisation"); 

Instance  threatened  =  _gh5KB.getObjectltem(threatenedOrganisationName); 

Instance  threat  =  _gh5KB.getObjectltem(threateningOrganisationName); 

List  candidateCoAs  =  new  LinkedList(); 

candidateCoAs.add(new  FormulateDEFEND(_gh5KB,  ^organisation,  threatened,  threat)); 
candidateCoAs. add(new  RequestPermissionToWithdraw(_gh5KB,  ^organisation,  threatened,  threat)); 
candidateCoAs. add(new  OrderThreatenedOrgToWithdraw(_gh5KB,  organisation,  threatened,  threat)); 
candidateCoAs. add(new  SupportThreatenedOrg(_gh5KB,  organisation,  threatened,  threat)); 

//  For  each  organisation  that  we  command,  add  appropriate  candidate  CoAs. 

Collection  OlAs  =  organisation. getOwnSlotValues(  gh5KB.getSlot("is-the-subiect-of-ObiectltemAssociation")); 
for  ( Iterator  oalter  =  OIAs.iterator();  oalter.hasNext(); )  { 

Instance  oia  =  (lnstance)oalter.next(); 

//  We  want  an  organisation  that  we  command. 

Instance  subordinateOrg  =  (lnstance)oia.getOwnSlotValue(_gh5KB.getSlot("object-is-associated-with-ObjectltemAssociation")); 
if  ( !  subordinateOrg. instanceOf(orgCls) ) 

continue; 

if  ( !  "CMDCTL".equals(_gh5KB.getCodeSlot(oia,  "categoryCode")) ) 

continue; 

if  (_gfi5KB.getObjectltemName(subordinateOrg).equals(threatenedOrganisationName)  || 

_gfi5KB.commands(subordinateOrg,  threatened) ) 

continue; 

Diagnostics. domainEvent("Adding  candidate  CoAs  for  subordinate  "  +  _gh5KB.getObjectltemName(subordinateOrg),  this); 
candidateCoAs. add(new  OrderOtherOrgToSupport(_gh5KB,  organisation,  threatened,  threat,  subordinateOrg)); 
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candidateCoAs.add(new  OrderThreatenedOrgToWithdraw(  gh5KB,  organisation,  threatened,  threat,  subordinateOrg)); 

} 

Diagnostics. domainEvent(  "Prioritizing  "  +  candidateCoAs.size()  +  "  CoA(s)  and  notifying  "  +  _gh5KB.getObjectltemName(_organisation), 

this); 

Collections. sort(candidateCoAs); 

String  trs  =  +  threateningOrganisationName  +  "\"  is  threatening  V"  +  threatenedOrganisationName  +  "V"; 

_notifier.signal(new  ThreatResponseNotification(trs,  candidateCoAs)); 

} 

I** 

*  Callback  method  invoked  through  {@link  ThreatStmtContext}  in  response  to  a  message  noting  a  cancelled  threat.  If  we  are  the  organisation 

*  that's  no  longer  threatened,  we  can  take  appropriate  action. 

*  @param  threateningOrganisationName  The  name  of  the  organisation  that's  no  longer  threatening 

*  <code>threatenedOrganisationName</code>. 

*  @param  threatenedOrganisationName  The  name  of  the  organisation  that's  no  longer  threatened  by 

<code>threateningOrganisationName</code>. 

*  @todo  Implement  this  method! 

**  j 

void  respondToThreatCancellation(String  threateningOrgName,  String  threatenedOrgName)  { 

Diagnostics. domainEventfCancelling  threat  by  "  +  threateningOrgName  +  "  to  "  +  threatenedOrgName,  this); 
if  ( _gh5KB.getObjectltemName(_organisation).equals(threatenedOrgName) )  { 

//  We  are  no  longer  threatened  by  the  org. 

//  Of  course,  we  may  still  be  threatened  by  other  orgs. 

} 

else  { 

} 

} 

} 

6.3.  Class  CourseOfAction 

Class  CourseOfAction  is  the  superclass  of  all  classes  that  denote  a  possible  course  of  action  a  threat  response  agent  might  formulate. 
Most  of  its  methods  are  procedural  abstractions  of  functionality  used  in  subclasses. 

A  course  of  action  can  be  evaluated.  Evaluation  is  responsible  for  determining  the  appropriateness  of  a  specific  course  of  action  in  re¬ 
sponse  to  a  threat.  Appropriateness  is  measured  by  a  floating-point  value  between  0  and  1,  inclusive.  0  means  the  course  of  action  is 
inappropriate.  1  means  the  course  of  action  is  appropriate,  that  is,  it  has  no  unforeseen  risks. 
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The  class  also  contains  two  abstract  methods  that  subclasses  must  implement.  The  first,  asC4IModel(),  must  state  the  course  of  action  in 
tenns  of  the  GH  ontology.  In  other  words,  it  must  return  a  list  of  related  instances  that  express  the  course  of  action  to  the  best  of  the 
GH  ontology’s  ability. 

The  second,  description(),  states  the  course  of  action  textually.  The  asC4IModel()  method  is  used  to  build  information  for  the  knowledge 
base;  the  description()  method  provides  information  for  consumption  by  a  human. 

package  ida.bh.cro.friendlyorg. threat. response; 

import  java. text. SimpleDateFormat; 

import  java. util. Calendar; 
import  java. util. Iterator; 
import  java. util. LinkedList; 
import  java. util. List; 

import  ida.sd.gh5ontology.*; 
import  ida.sd. ontology.*; 

I** 

*  The  <code>CourseOfAction</code>  class  is  the  superclass  of  all  courses  of  action  in  response  to  a  threat. 

*  <p>Evaluating  a  course  of  action  depends  on  at  least  three  organisations: 

*  <ol> 

*  <li>The  organisation  that  is  formulating  a  response  to  a  threat  notification  (that  is,  us).</li> 

*  <li>The  organisation  that  is  determined  to  be  threatened.  This  may  or  may  not  be  us.</li> 

*  <li>The  organisation  that  is  the  threat. </li> 

*  </ol> 

*  The  secret  of  this  class  is  the  data  structures  for  representing  course-of-  action  information.  The  secret  of  subclasses  includes  the  algorithms 

*  for  implementing  the  {@link  #value  value}  method. 

*  <p>A  subclass  has  the  responsibility  to: 

*  <ol> 

*  <li>Define  the  nature  of  a  specific  course  of  action. </li> 

*  <li>{@linkplain  #asC4IModel  Translate}  an  instance  of  itself  into  a  set  of  {@linkplain  ida.sd.ontology. Instance  instances}  that  are  a  GH5 

*  expression  of  the  course  of  action  the  instance  denotes. </li> 

*  </ol> 

**  i 

public  abstract  class  CourseOfAction 
implements  Comparable  { 

protected  final  GH5KB  _gh5KB; 

/**  The  organisation  formulating  a  response  to  a  threat  notification.  */ 

protected  final  Instance  us; 
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/**  An  organisation  that's  been  determined  as  threatened.  */ 
protected  final  Instance  threatened; 

/**  The  organisation  that's  threatening  the  {@linkplain  #_threatened  threatened  organisation}.  */ 

protected  final  Instance  threat; 

/**  Holds  textual  statements  of  rationale  behind  estimating  a  course  of  action's  effectiveness.  */ 
protected  List_rationale  =  new  LinkedList(); 

/**  The  name  of  the  threatened  organisation.  All  subclasses  tend  to  use  it  at  some  point.  */ 
protected  final  String  -threatenedOrgName; 

II  The  following  are  some  constants  useful  for  stating  rationales, 
protected  final  static  String  NOT_THREATENED  =  "We  are  not  threatened."; 
protected  final  static  String  THREATENED  =  "We  are  threatened."; 

protected  final  static  String  NOT  T ASKED  =  "We  are  not  otherwise  tasked."; 
protected  final  static  String  TASKED  =  "We  are  otherwise  tasked."; 

protected  final  static  String  SUPPLIES_ADEQUATE  =  "Our  supplies  are  adequate  for  defense  against  the  threat."; 
protected  final  static  String  SUPPLIESJNADEQUATE  =  "Our  supplies  are  not  adequate  for  defense  against  the  threat."; 

jit* 

*  Constructs  a  <code>CourseOfAction</code>,  storing  the  arguments  in  protected  fields.  A  subclass  must  extend  the  constructor  to  set  the 

*  {@link  #_value}  field. 

*  @param  us  The  organisation  formulating  a  response  to  a  threat  notification. 

*  @param  threatened  An  organisation  that's  been  determined  as  threatened. 

*  @param  threat  The  organisation  that's  a  threat. 

**  j 

public  CourseOfAction(GH5KB  gh5KB,  Instance  us,  Instance  threatened,  Instance  threat)  { 

_gh5KB  =  gh5KB; 

_us  =  us; 

-threatened  =  threatened; 

_threat  =  threat; 

-threatenedOrgName  =  _gh5KB.getObjectltemName(_threatened); 

} 

/**  The  efficiency  of  this  course  of  action.  Subclass  constructors  must  set  its  value.  */ 
protected  float  _value; 

jit* 

*  Returns  a  value  between  0.0  and  1 .0  (inclusive)  denoting  the  level  of  effectiveness  of  a  course  of  action  in  response  to  a  threat. 

**  j 

public  float  valueQ  { 
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return  value; 


} 

I** 

*  Returns  a  textual  description  of  the  course  of  action. 

*  @return  A  textual  description  of  the  course  of  action. 

**  i 

public  abstract  String  description(); 

jit* 

*  Gets  statements  of  rationale  that  have  been  added. 

**  i 

public  List  getRationale()  { 
return  rationale; 

} 

I** 

*  Converts  this  course  of  action  into  a  {@link  java. util. List}  of  {@link  ida.sd.ontology.lnstancejs.  These  instances 

*  express  this  course  of  action  in  terms  of  the  GH5. 

*  <p>An  implementation  of  this  method  is  not  responsible  for  saving  these  actions  into  the  underlying  DB,  if  one  is  present.  The  caller  has 

*  that  responsibility. 

*  <p>The  list  must  be  sorted  such  that  saving  it  into  the  underlying  DB  will  not  violate  integrity  constraints.  It  is  hoped  that  this 

*  restriction  will  be  removed  in  the  future. 

*  @return  A  list  of  entities  and  relationships  that  express  this  course  of  action. 

**  i 

public  abstract  List  asC4IModel(); 

//  Many  courses  of  action  need  to  know  about  the  threatened  org's  location  and  the  threat's  time  to  reach  it.  The  following  fields 
//  and  methods  support  such  calculations. 

private  float  timingRatio; 
private  String  orgName; 

jit* 

*  Finds  the  times  needed  for  two  organisations  --  one  of  which  is  {@link  #_threat  _threat}  --  to  reach  a  location,  and  returns  the  ratio  of  those 

*  times.  Has  two  side  effects: 

*  <ol> 

*  <li>Stores  the  timing  ratio  and  the  name  of  <code>org</code>,  which  is  useful  in  a  subsequent  use  of  {@link  #timingRatioMessage()}.</li> 

*  <li>lf  an  exception  is  thrown,  adds  an  explanation  of  why  to  {@link  #_rationale  _rationale}.</li> 

*  </ol> 

*  @param  org  An  {@link  ida.sd. ontology. Instance}  of  Organisation. 

*  @param  loc  An  {@link  ida.sd. ontology. Instance}  of  Location. 
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*  @return  The  time  <code>org</code>  needs  to  reach  <code>loc</code>  divide  by  the  time  {@link  #_threat  _threat}  needs  to  reach 

*  <code>loc</code>,  or  1.0,  whichever  is  smaller. 

*  @throws  IncomputableException  If  either  organisation  lacks  a  location  or  a  speed. 

**  j 

protected  float  timingRatio(lnstance  org,  Instance  loc) 
throws  IncomputableException  { 
float  timeForOrgToReachLoc; 

try  { 

timeForOrgToReachLoc  =  _gh5KB.estimatedTimeToReach(org,  loc).floatValue(); 

}  catch  (  NoLocationException  e  )  { 

_rationale.add("Can't  determine  location  of "  +  _gh5KB.getObjectltemName(org)  + 
throw  new  IncomputableException(e); 

}  catch  (  SpeedlndeterminateException  e  )  { 

_rationale.add("Can't  determine  speed  of "  +  _gh5KB.getObjectltemName(org)  + 
throw  new  IncomputableException(e); 

} 

float  timeForThreatToReachLoc; 

try  { 

timeForThreatToReachLoc  =  _gh5KB.estimatedTimeToReach(_threat,  loc).floatValue(); 

}  catch  (  NoLocationException  e  )  { 

_rationale.add("Can't  determine  location  of "  +  _gh5KB.getObjectltemName(_threat)  + 
throw  new  IncomputableException(e); 

}  catch  (  SpeedlndeterminateException  e  )  { 

_rationale.add("Can't  determine  speed  of "  +  _gh5KB.getObjectltemName(_threat)  + 
throw  new  IncomputableException(e); 

} 

_timingRatio  =  timeForOrgToReachLoc/timeForThreatToReachLoc; 

_orgName  =  _gh5KB.getObjectltemName(org); 
return  _timingRatio  <=1.0?  _timingRatio  :  1  .Of; 

} 

I** 

*  Like  {@link  #timingRatio(lnstance,  Instance)  timingRatio},  but  also  can  add  a  message  to  {@link  #_rationale  _rationale}. 

*  The  message  is  constructed  from  {@link  #timingRatioMessage()}. 

*  @param  org  See  {@link  #timingRatio(lnstance,  Instance)  timingRatio}. 

*  @param  loc  See  {@link  #timingRatio(lnstance,  Instance)  timingRatio}. 

*  @param  addMessage  If  true,  adds  the  message  to  {@link  #_rationale}.  If  false,  does  not  add  the  message. 

*  @return  See  {@link  #timingRatio(lnstance,  Instance)  timingRatio}. 
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*  @throws  IncomputableException  See  {@link  #timingRatio(lnstance,  Instance)  timingRatio}. 

**  j 

protected  float  timingRatio(lnstance  org,  Instance  loc,  boolean  addMessage) 
throws  IncomputableException  { 
float  r  =  timingRatio(org,  loc); 
if  ( addMessage  ) 

_rationale.add(timingRatioMessage()); 

return  r; 

} 

jit* 

*  Standardizes  the  rationale  message  for  timing  ratios.  Only  valid  for  the  ratio  computed  from  the  last  invocation  of  {@link  #timingRatio}. 

**  j 

protected  String  timingRatioMessage()  { 
if  ( _timingRatio  >  1  .Of ) 

return  _orgName  +  "  can't  reached  threatened  location  before  "  +  _gh5KB.getObjectltemName(_threat)  + 

else 

return  _orgName  +  "  will  reach  threatened  location  in  "  +  _timingRatio  +  "%  of  time  that "  +  _gh5KB.getObjectltemName(_threat)  + 

"will."; 

} 

II  The  following  fields  and  methods  support  the  construction  of  ontology  updates. 

protected  final  static  String  ORDER  AT  CC  =  "ORD"; 
protected  final  static  String  PLANATCC  =  "PLAN"; 

protected  final  static  String  DEFEND_AT_VPC  =  "DEFEND"; 
protected  final  static  String  MOVE  AT  VPC  =  "MOVE"; 

protected  final  static  String  ORDER  ATS  CC  =  "ORD"; 
protected  final  static  String  PLANATSCC  =  "PLAN"; 

private  final  static  SimpleDateFormat  DATE_FORMAT  =  new  SimpleDateFormat("yyyyMMdd"); 

j ** 

*  Provides  a  <code>ReportingData  {@link  ida.sd. ontology. Instance  instance}  that  describes  a  planned  <code>ActionTask</code>.  A 

*  procedural  abstraction  that  supports  the  {@link  #asC4IModel()}  method. 

*  @param  day  The  day  to  use  for  the  reporting  date.  If  null,  use  today. 

*  @param  time  The  time  to  use  for  the  reporting  date.  If  null,  use  now. 

**  j 

protected  Instance  updateReportingData(Calendar  dateTime)  { 

Instance  rd  =  _gh5KB.getCls("ReportingDataAbsoluteTiming").createDirectlnstance(); 

try  { 
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_gh5KB.setCodeSlot(rd,  "timingCategoryCode",  "RDABST"); 

_gh5KB.setCodeSlot(rd,  "reliabilityCode",  "A"); 

_gh5KB.setCodeSlot(rd,  "sourceTypeCode",  "HUMINT"); 

_gh5KB.setCodeSlot(rd,  "credibilityCode",  "RPTFCT"); 

_gh5KB.setCodeSlot(rd,  "categoryCode",  "REP"); 

_gh5KB.setCodeSlot(rd,  "countinglndicatorCode",  "NO"); 

_gh5KB.setCodeSlot(rd,  "accuracyCode",  "3"); 

_gh5KB.setCodeSlot(rd,  "entityCategoryCode",  "ACTTST"); 

if  (  dateTime  !=  null )  { 


_gh5KB.setDateSlot(rd,  "reportingDate",  dateTime); 

_gh5KB.setTimeSlot(rd,  "reportingTime",  dateTime); 

_gh5KB.setDateSlot(rd,  "effectiveDate",  dateTime); 

_gh5KB.setTimeSlot(rd,  "effectiveTime",  dateTime); 

} 

_gh5KB.setCodeSlot(rd,  "effectiveTimePrecisionCode",  "SECOND"); 

_gh5KB.setlntSlot(rd,  "duration",  new  lnteger(30));  //  30  is  arbitrary.  Should  probably  be  a  parameter. 

}  catch  ( InvalidCodeException  e  )  { 
throw  new  Error(e); 

} 

return  rd; 

} 

jit* 

*  Provides  an  OrganisationActionAssociation  {@link  ida.sd. ontology. Instance}  that  can  relate  {@link  #_us}  to  an  action.  The  caller  may  want 

*  to  set  the  IntentText  field. 

*  @param  day  The  day  to  use  for  the  reporting  date.  If  null,  use  today. 

*  @param  time  The  time  to  use  for  the  reporting  date.  If  null,  use  now. 

**  i 

protected  Instance  updateOAA(Calendar  dateTime)  { 

Instance  oaa  =  _gh5KB.getCls("OrganisationActionAssociation").createDirectlnstance(); 

try  { 

_gh5KB.setCodeSlot(oaa,  "categoryCode",  "REQUST"); 

}  catch  ( InvalidCodeException  e  )  { 
throw  new  Error(e); 

} 

if  (  dateTime  !=  null )  { 

_gh5KB.setDateSlot(oaa,  "effectiveDate",  dateTime); 

_gh5KB.setTimeSlot(oaa,  "effectiveTime",  dateTime); 
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return  oaa; 


} 

I** 

*  Provides  an  <code>ActionTaskStatus</code>  {@link  ida.sd. ontology. Instance}  that  is  suited  to  a  proposed  course  of  action. 

*  @param  categoryCode  The  category  code  for  the  <code>ActionTaskStatus</code>. 

**  j 

protected  Instance  updateActionTaskStatus(String  categoryCode)  { 

Instance  ts  =  _gh5KB.getCls("ActionTaskStatus").createDirectlnstance(); 

try  { 

_gh5KB.setCodeSlot(ts,  "categoryCode",  categoryCode); 

_gh5KB.setCodeSlot(ts,  "timingCode",  "RQESAT"); 

_gh5KB.setCodeSlot(ts,  "progressCode",  "NST"); 

}  catch  ( InvalidCodeException  e  )  { 
throw  new  Error(e); 

} 

_gh5KB.setFloatSlot(ts,  "completionFraction",  new  Double(O.O)); 

return  ts; 

} 

protected  Instance  updateActionTask(String  name,  String  categoryCode,  String  activityCode,  String  detaillntro)  { 

Instance  t  =  _gh5KB.getCls("ActionTask").createDirectlnstance(); 

try  { 

_gh5KB.setStringSlot(t,  "name",  "Support"); 

_gh5KB.setCodeSlot(t,  "categoryCode",  categoryCode); 

_gh5KB.setCodeSlot(t,  "activityCode",  activityCode); 

_gh5KB.setCodeSlot(t,  "priorityCode",  "1"); 

_gh5KB.setCodeSlot(t,  "startQualifierCode",  "ASAP"); 

II  Consider  formatting  this  in  HTML. 

StringBuffer  detail  =  new  StringBuffer(detaillntro); 
for  ( int  i  =  0;  i  <  _rationale.size();  i++  ) 

detail. append("\n").append(i).append(")  ").append(_rationale.get(i)); 

_gh5KB.setStringSlot(t,  "detailText",  detail. toString()); 

}  catch  ( InvalidCodeException  e  )  { 
throw  new  Error(e); 

}  catch  (  StringLengthException  e  )  { 
throw  new  Error(e); 

} 

return  t; 
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} 

protected  void  establishRelations(lnstance  targetOrg, 

Instance  reportingOrg, 

Instance  reportingData, 

Instance  task, 

Instance  taskStatus, 

Instance  oaa)  { 

task.addOwnSlotValue(  qh5KB.getSlot("has-ActionTaskStatus"),  taskStatus); 

reportingData. addOwnSlotValue(_gh5KB.getSlot("provides-applicable-information-for-ActionTaskStatus"),  taskStatus); 
targetOrg. addOwnSlotValue(_gh5KB.getSlot("has-its-role-specified-through-OrganisationActionAssociation"),  oaa); 
task.addOwnSlotValue(_gh5KB.getSlot("is-acted-upon-as-specified-by-OrganisationActionAssociation"),  oaa); 
reportingOrg. addOwnSlotValue(_gh5KB.getSlot("is-the-reporting-agent-for-ReportingData"),  reportingData); 

} 

protected  List  collectedEntities(lnstance  reportingData,  Instance  actionTask,  Instance  actionTaskStatus,  Instance  oaa)  { 
List  c4IEntities  =  new  LinkedList(); 
c4IEntities.add(reportingData); 
c4IEntities.add(actionTask); 
c4IEntities.add(actionTaskStatus); 
c4IEntities.add(oaa); 

return  c4IEntities; 

} 

jit* 

*  Signals  that  a  timing  ratio  is  not  computable. 

**  i 

protected  class  IncomputableException  extends  Exception  { 

jit* 

*  Constructs  an  <code>lncomputableException</code>. 

*  @param  e  The  reason  why  the  timing  ratio  can't  be  computed.  The  intent  is  that  it  come  from  the  method  that  couldn't 

*  compute  the  ratio. 

**  i 

public  lncomputableException(Exception  e)  { 
super("Timing  ratio  incomputable",  e); 

} 

} 

I** 

*  Implements  the  {@link  java. lang. Comparable}  interface  for  this  class. 
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*  @param  o  Something  that  had  better  be  a  <code>CourseOfAction</code>. 

*  @return  See  {@link  java. lang. Comparable}. 

*  @see  java. lang. Comparable 

**  j 

public  int  compareTo(Object  o)  { 

//  We  negate  the  comparison:  we  want  largest  values  first, 
float  otherValue  =  ((CourseOfAction)o).value(); 
if  ( _value  <  otherValue  ) 

return  1; 

else  if  ( _value  >  otherValue  ) 

return  -1 ; 
else 

return  0; 

} 

} 

6.4.  Class  FormulateDefend 

The  FormulateDefend  class  is  one  possible  course  of  action  in  response  to  a  threat.  The  functionality  in  this  class  evaluates  whether 
holding  one’s  position  to  defend  against  a  threat  is  an  appropriate  course  of  action. 

A  value  of  0  does  not  necessarily  mean  that  the  threat  is  overwhelming.  0  is  also  assigned  if  the  organization  evaluating  the  threat  is 
not  the  one  that’s  threatened. 

package  ida.bh.cro.friendlyorg. threat. response; 

import  java. util. Calendar; 
import  java. util. List; 

import  ida.sd.gh5ontology.GH5KB; 

import  ida.sd.gh5ontology.StringLengthException; 

import  ida.sd.ontology. Instance; 

public  class  FormulateDEFEND 
extends  CourseOfAction  { 

I** 

*  Constructs  a  <code>FormulateDEFEND</code>  which  will  evaluate  the  effectiveness  of  <code>us</code>  formulating  a  DEFEND  action. 

*  @param  us  The  organisation  that  is  evaluating  whether  defending  its  current  location  is  an  effective  course  of  action. 

*  @param  threatened  An  organisation  that  has  been  determined  to  be  threatened. 

*  @param  threat  An  organisation  that  threatens  <code>threatened</code>. 

**  j 
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public  FormulateDEFEND(GH5KB  gh5KB,  Instance  us,  Instance  threatened,  Instance  threat)  { 
super(gh5KB,  us,  threatened,  threat); 

if  ( !  _us.getName().equals(threatened.getName()) )  { 

rationale. addfNOT  THREATENED);  //  Nothing  to  defend  against. 

_value  =  O.Of; 

return; 

} 

_rationale.add(THREATENED); 

if  ( _gh5KB.currentTask(_us)  !=  null )  { 

_rationale.add(TASKED);  //  We  already  have  a  task. 

_value  =  O.Of; 

return; 

} 

_rationale.add(NOT_TASKED); 

double  supplyAdequacy  =  _gh5KB.supplyAdequacy(_us); 
if  (  supplyAdequacy  >=  0.5  )  { 

_rationale.add(SUPPLIES_ADEQUATE); 

_value  =  (float)supplyAdequacy; 

return; 

} 

else  { 

_rationale.add(SUPPLIES_INADEQUATE); 

_value  =  O.Of; 

return; 

} 

} 

public  String  description()  { 

return  "We  formulate  a  DEFEND  action  in  response  to  the  threat."; 

} 

I** 

*  Creates  the  list  of  C4I  entities  that  reflect  a  DEFEND  task. 

*  @return  The  list  of  C4I  entities  that  reflect  a  DEFEND  task. 

**  j 

public  List  asC4IModel()  { 

Calendar  now  =  Calendar.getlnstance(); 

Instance  reportingData  =  updateReportingData(now); 
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Instance  task  =  updateActionTask("DEFEND",  PLAN_AT_CC,  DEFEND_AT_VPC, 

"We  shall  defend  in  response  to  the  threat  from  "  +  _threat.getName()  + 

_gh5KB.setDateSlot(task,  "plannedStartDate",  now); 

Instance  taskStatus  =  updateActionTaskStatus(PLAN_ATS_CC); 

Instance  oaa  =  updateOAA(now); 

try  { 

_gh5KB.setStringSlot(oaa,  "intentText",  "We  intend  to  defend  our  position."); 

}  catch  (  StringLengthException  e  )  { 
throw  new  Error(e); 

} 

establishRelations(_us,  _us,  reportingData,  task,  taskStatus,  oaa); 
return  collectedEntities(reportingData,  task,  taskStatus,  oaa); 

} 

} 

6.5.  Class  OrderOtherOrgToSupport 

The  OrderOtherOrgToSupport  class  is  one  possible  course  of  action  in  response  to  a  threat.  The  functionality  in  this  class  evaluates 
whether  issuing  an  order  to  another  organization  to  support  the  threatened  organization  is  appropriate.  Assessing  appropriateness  in 
this  case  includes  determining  whether  the  organization  evaluating  the  course  of  action  has  authority  to  issue  orders  to  other  organiza¬ 
tions. 

package  ida.bh.cro.friendlyorg. threat. response; 

import  java. util. Calendar; 
import  java. util. List; 

import  ida.sd.gh5ontology.GH5KB; 

import  ida.sd.gh5ontology.StringLengthException; 

import  ida.sd. ontology. Instance; 

public  class  OrderOtherOrgToSupport 
extends  CourseOfAction  { 

private  final  Instance  subordinate; 

jit* 

*  Constructs  an  <code>OrderOtherOrgToSupport</code>  which  will  evaluate  the  effectiveness  of  us  ordering  a  subordinate  organisation  to 

*  support  a  threatened  organisation. 

*  @param  us  The  organisation  that  is  evaluating  whether  requesting  permission  to  withdraw  is  an  effective  course  of  action. 
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*  @param  threatened  An  organisation  that  has  been  determined  to  be  threatened. 

*  @param  threat  An  organisation  that  threatens  <code>org</code>. 

*  @param  subordinate  An  organisation  commanded  by  us. 

**  i 

public  OrderOtherOrgToSupport(GH5KB  gh5KB,  Instance  us,  Instance  threatened,  Instance  threat,  Instance  subordinate)  { 
super(gh5KB,  us,  threatened,  threat); 

_subordinate  =  subordinate; 

if  ( _gh5KB.getObjectltemName(_us).equals(_threatenedOrgName) )  { 

_rationale.add("We  are  the  threatened  organisation.");  //  Actually,  if  we  command  other  orgs,  we 
_value  =  O.Of;  //  could  still  have  them  support  us.  Later. 

return; 

} 

_rationale.add("We  are  not  the  threatened  organisation."); 

if  ( !  _gh5KB.commands(_us,  -threatened) )  { 

_rationale. addfWe  do  not  command  the  threatened  organisation."); 

_value  =  O.Of; 

return; 

} 

-rationale. add("We  command  the  threatened  organisation."); 

Instance  subordinateTask  =  _gh5KB.currentTask(_subordinate); 
if  (  subordinateTask  ==  null )  { 

rationale. add(  gh5KB.getObjectltemName(  subordinate)  +  "  is  not  otherwise  tasked."); 

_value  =  (float)_gh5KB.supplyAdequacy(_subordinate); 
if  ( _value  <=  0.5f )  { 

-rationale.  addfSupplies  of"  +  _gh5KB.getObjectltemName(_subordinate)  +  "  are  inadequate."); 

return; 

} 

-rationale. addfSupplies  of "  +  _gh5KB.getObjectltemName(_subordinate)  +  "  are  adequate."); 

float  timingRatio; 

try  { 

Instance  threatenedLocation  =  _gh5KB.getCurrentLocation(_threatened); 
if  ( threatenedLocation  ==  null  )  { 

-rationale. addfCan't  determine  location  of "  +  _threatenedOrgName); 

_value  =  O.Of; 

return; 

} 
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timingRatio  =  timingRatio(_subordinate,  threatenedLocation); 

}  catch  ( IncomputableException  e  )  { 

_rationale.add("Can't  determine  timing  ratio  for "  +  _gh5KB.getObjectltemName(_subordinate)); 

_value  =  O.Of; 

return; 

} 

_rationale.add(timingRatioMessage()); 

_value  *=  1  .Of  -  timingRatio; 

return; 

} 

else  { 

rationale. add(  gh5KB.getObjectltemName(  subordinate)  +  "  is  otherwise  tasked."); 

//  Ultimately,  evaluate  the  subordinate's  task.  For  now,  assume  it's  critical. 

_value  =  O.Of; 

return; 

} 

} 

public  String  description()  { 

return  "We  order "  +  _gh5KB.getObjectltemName(_subordinate)  +  "  to  support "  +  _threatenedOrgName  + 

} 

I** 

*  Creates  the  list  of  C4I  entities  that  reflect  an  order  for  a  subordinate  organisation  to  support  a  friendly  organisation  identified  as  threatened. 

*  This  is  formulated  as  an  order  to  move. 

*  @return  The  list  of  C4I  entities  that  reflect  the  request. 

**  j 

public  List  asC4IModel()  { 

Calendar  now  =  Calendar.getlnstance(); 

Instance  reportingData  =  updateReportingData(now); 

Instance  actionTaskStatus  =  updateActionTaskStatus(ORDER_ATS_CC); 

Instance  oaa  =  updateOAA(now); 

String  subordinateName  =  _gh5KB.getObjectltemName(_subordinate); 

try  { 

_gh5KB.setStringSlot(oaa,  "intentText",  "We  intend  "  +  subordinateName  +  "  to  support "  +  _threatenedOrgName); 

}  catch  (  StringLengthException  e  )  { 
throw  new  Error(e); 

} 
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} 


Instance  actionTask  =  updateActionTask("Support",  ORDER_AT_CC,  MOVE_AT_VPC, 

"We  shall  move  to  the  location  of "  + 
subordinateName  + 

"  in  response  to  the  threat  from  "  + 
_gh5KB.getObjectltemName(_threat)  + 

"  to "  + 


_threatenedOrgName  + 

ii.ii^. 

_gh5KB.setDateTimeSlots(actionTask,  "plannedStartDate", 


plannedStartTime",  now); 


establishRelations(_subordinate,  _us,  reportingData,  actionTask,  actionTaskStatus,  oaa); 


return  collectedEntities(reportingData,  actionTask,  actionTaskStatus,  oaa); 


6.6.  Class  OrderThreatenedOrgToWithdraw 

The  OrderThreatenedOrgToWithdraw  class  is  one  possible  course  of  action  in  response  to  a  threat.  The  functionality  in  this  class  evalu 
ates  whether  ordering  the  organization  that  is  threatened  to  withdraw  from  its  current  position  is  an  appropriate  course  of  action.  As 
sessing  appropriateness  in  this  case  includes  determining  whether  the  organization  evaluating  the  course  of  action  has  authority  to  is 
sue  orders  to  other  organizations. 

package  ida.bh.cro.friendlyorg. threat. response; 

import  java. util. Calendar; 
import  java. util. List; 

import  ida.sd.gh5ontology.GH5KB; 

import  ida.sd.gh5ontology.StringLengthException; 

import  ida.sd. ontology. Instance; 

public  class  OrderThreatenedOrgToWithdraw 
extends  CourseOfAction  { 

private  final  Instance  subordinate; 

jit* 

*  Constructs  an  <code>OrderThreatenedOrgToWithdraw</code>  that  will  evaluate  the  effectiveness  of  us  giving  a  threatened  organisation  an 

*  order  to  withdraw. 

*  @param  us  The  organisation  that  is  evaluating  whether  requesting  permission  to  withdraw  is  an  effective  course  of  action. 

*  @param  threatened  An  organisation  that  has  been  determined  to  be  threatened. 

*  @param  threat  An  organisation  that  threatens  <code>org</code>. 
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*  @param  subordinate  An  organisation  commanded  by  us.  We  evaluate  whether  this  organisation  is  available  to  support 

*  the  threatened  organisation. 

**  j 

public  OrderThreatenedOrgToWithdraw(GH5KB  gh5KB,  Instance  us,  Instance  threatened,  Instance  threat,  Instance  subordinate)  { 
super(gh5KB,  us,  threatened,  threat); 

_subordinate  =  subordinate; 

if  ( _gh5KB.getObjectltemName(_us).equals(_threatenedOrgName) )  { 

_rationale.add("We  are  the  threatened  organisation."); 

_value  =  O.Of; 

return; 

} 

_rationale.add("We  are  not  the  threatened  organisation."); 

if  ( !  _gh5KB.commands(_us,  -threatened) )  { 

_rationale. addfWe  do  not  command  the  threatened  organisation."); 

_value  =  O.Of; 

return; 

} 

-rationale. add("We  command  the  threatened  organisation."); 

float  supplyAdequacy; 
if  ( -Subordinate  !=  null )  { 

-rationale. addfWe  can  command  "  +  _gh5KB.getObjectltemName(_subordinate)); 

float  timingRatio; 

try  { 

Instance  threatenedLocation  =  _gh5KB.getCurrentLocation(_threatened); 
if  ( threatenedLocation  ==  null )  { 

-rationale. addfCan't  determine  location  of "  +  _threatenedOrgName); 

_value  =  O.Of; 

return; 

} 

timingRatio  =  timingRatio(_subordinate,  threatenedLocation); 

}  catch  ( IncomputableException  e  )  { 

_value  =  O.Of; 

return; 

} 

Instance  subordinateTask  =  _gh5KB.currentTask(_subordinate); 
if  (  subordinateTask  ==  null )  { 
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rationale. add(  gh5KB.getObiectltemName(  subordinate)  +  "  is  not  otherwise  tasked."); 

supplyAdequacy  =  (float)_gh5KB.supplyAdequacy(_subordinate); 
if  (  supplyAdequacy  <  0.5f )  { 

rationale. add(  gh5KB.getObiectltemName(  _subordinate)  + 

"  cannot  support "  + 

_threatenedOrgName  + 

"  (inadequate  supplies)."); 

_value  =  1  .Of  -  supplyAdequacy; 

return; 

} 

rationale. add(  gh5KB.getObiectltemName(  subordinate)  +  "  has  adequate  supplies  to  support " 

Rationale. add(timingRatioMessage()); 

_value  *=  timingRatio; 

return; 

} 

else  { 

rationale. add(  gh5KB.getObiectltemName(  subordinate)  +  "  is  otherwise  tasked."); 

//  Ultimately,  evaluate  the  subordinate's  task.  For  now,  assume  it's  critical. 
_rationale.add(timingRatioMessage()); 

_value  *=  timingRatio; 

return; 

} 

} 

else  { 

_rationale.add("No  subordinate  organisation  to  command  to  support "  +  _threatenedOrgName  +  "."); 

supplyAdequacy  =  (float)_gh5KB.supplyAdequacy(_threatened); 

_value  =  1  .Of  -  supplyAdequacy; 
if  (  supplyAdequacy  <  0.6f )  { 

_rationale.add(_threatenedOrgName  +  "  has  inadequate  supplies  to  defend  itself."); 

return; 

} 

else  { 

_rationale.add(_threatenedOrgName  +  "  has  adequate  supplies  to  defend  itself."); 

return; 

} 

} 

} 


threatenedOrgName  +  " 
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I** 

*  Constructs  an  <code>OrderThreatenedOrgToWithdraw</code>  which  will 

*  evaluate  the  effectiveness  of  us  giving  a  threatened  organisation  an  order  to  withdraw. 

*  @param  us  The  organisation  that  is  evaluating  whether  requesting  permission  to  withdraw  is  an  effective  course  of  action. 

*  @param  threatened  An  organisation  that  has  been  determined  to  be  threatened. 

*  @param  threat  An  organisation  that  threatens  <code>org</code>. 

**  j 

public  OrderThreatenedOrgToWithdraw(GH5KB  gh5KB,  Instance  us,  Instance  threatened,  Instance  threat)  { 
this(gh5KB,  us,  threatened,  threat,  null); 

} 

public  String  description()  { 

return  "We  order  subordinate  organisation  "  +  _threatenedOrgName  +  "  to  withdraw."; 

} 

I** 

*  Creates  the  list  of  C4I  entities  that  reflect  an  order  to  withdraw.  This  is  formulated  as  an  order  to  move. 

*  <p>N.B.  I  believe  that  in  the  GH5  "withdraw"  means  to  disengage  from  contact  with  hostile  forces.  Here,  the  organisation  need  not 

*  actually  be  in  contact  with  the  forces;  it  must  only  be  aware  of  them. 

*  @return  The  list  of  C4I  entities  that  reflect  the  withdraw  order. 

**  j 

public  List  asC4IModel()  { 

Calendar  now  =  Calendar.getlnstance(); 

Instance  reportingData  =  updateReportingData(now); 

Instance  actionTaskStatus  =  updateActionTaskStatus(ORDER_ATS_CC); 

Instance  oaa  =  updateOAA(now); 

try  { 

_gh5KB.setStringSlot(oaa,  "intentText",  "We  intend  to  move  to  a  safe  location."); 

}  catch  (  StringLengthException  e  )  { 
throw  new  Error(e); 

} 

Instance  actionTask  =  updateActionTask(  "Withdraw", 

ORDERATCC, 

MO  VE_AT_VPC , 

"We  shall  move  to  a  safe  location  in  response  to  the  threat  from  "  + 
_gh5KB.getObjectltemName(_threat)  +  ":"); 

_gh5KB.setDateSlot(actionTask,  "plannedStartDate",  now); 

establishRelations(_us,  _us,  reportingData,  actionTask,  actionTaskStatus,  oaa); 
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return  collectedEntities(reportingData,  actionTask,  actionTaskStatus,  oaa); 

} 

} 

6.7.  Class  RequestPermissionToWithdraw 

The  RequestPermissionToWithdraw  class  is  one  possible  course  of  action  in  response  to  a  threat.  The  functionality  in  this  class  evaluates 
whether  the  organization  that  is  threatened  should  request  permission  from  its  superior  organization  to  withdraw  from  its  current  posi¬ 
tion. 

package  ida.bh.cro.friendlyorg. threat. response; 

import  java. util. Calendar; 
import  java. util. List; 

import  ida.sd.gh5ontology.GH5KB; 

import  ida.sd.gh5ontology.StringLengthException; 

import  ida.sd. ontology. Instance; 

public  class  RequestPermissionToWithdraw 
extends  CourseOfAction  { 

jit* 

*  Constructs  a  <code>RequestPermissionToWithdraw</code>  which  will  evaluate  the  effectiveness  of  us  requesting  permission  to  withdraw. 

*  @param  us  The  organisation  that  is  evaluating  whether  requesting  permission  to  withdraw  is  an  effective  course  of  action. 

*  @param  threatened  An  organisation  that  has  been  determined  to  be  threatened. 

*  @param  threat  An  organisation  that  threatens  <code>org</code>. 

**  j 

public  RequestPermissionToWithdraw(GH5KB  gh5KB,  Instance  us,  Instance  threatened,  Instance  threat)  { 
super(gh5KB,  us,  threatened,  threat); 

if  ( !  _gh5KB.getObjectltemName(_us).equals(_threatenedOrgName) )  { 

_rationale.add(NOT_THREATENED); 

_value  =  O.Of; 

return; 

} 

_rationale.add(THREATENED); 

float  supplyAdequacy  =  (float)_gh5KB.supplyAdequacy(_us); 

Instance  currentTask  =  _gh5KB.currentTask(_us); 
if  (  currentTask  !=  null )  { 

_rationale.add(TASKED); 
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String  activityCode  =  _gh5KB.getCodeSlot(currentTask,  "activityCode"); 

if  ( "DEFEND". equals(activityCode) )  { 

_rationale.add("We  are  tasked  to  DEFEND."); 

//  Make  the  value  inversely  proportional  to  supply  adequacy:  If  we  are  tasked  to  defend,  we  should  reject  withdrawal 
//  if  our  supplies  are  adequate. 

_value  =  1  .Of  -  supplyAdequacy; 
if  (  supplyAdequacy  >  0.6f )  { 

_rationale.add(SUPPLIES_ADEQUATE); 

return; 

} 

else  { 

_rationale.add(SUPPLIES_INADEQUATE); 

return; 

} 

} 

else  { 

_rationale.add("We  have  a  task  that  is  not  DEFEND."); 

_value  =  supplyAdequacy; 
if  (  supplyAdequacy  >  0.5f )  { 

_rationale.add(SUPPLIES_ADEQUATE); 

return; 

} 

else  { 

_rationale.add(SUPPLIES_INADEQUATE); 

return; 

} 

} 

} 

else  { 

_rationale.add(NOT_TASKED); 

//  If  we  aren't  tasked,  let's  stay  and  fight  if  our  supplies  are  high.  So  again,  make  _value  inversely  proportional  to  supplies. 
_value  =  1  .Of  -  supplyAdequacy; 
if  (  supplyAdequacy  >  0.8f )  { 

_rationale.add(SUPPLIES_ADEQUATE); 

return; 

} 

else  { 
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_rationale.add(SUPPLIES_INADEQUATE); 

return; 

} 

} 

} 

public  String  description()  { 

return  "We  request  permission  to  withdraw  from  our  location  in  response  to  the  threat."; 

} 

jit* 

*  Creates  the  list  of  C4I  entities  that  reflect  a  request  to  withdraw.  This  is  formulated  as  a  plan  to  move. 

*  <p>N.B.  I  believe  that  in  the  GH5  "withdraw"  means  to  disengage  from  contact  with  hostile  forces.  Here,  the  organisation  need  not 

*  actually  be  in  contact  with  the  forces;  it  must  only  be  aware  of  them. 

*  @return  The  list  of  C4I  entities  that  reflect  the  withdraw  request. 

**  j 

public  List  asC4IModel()  { 

Calendar  now  =  Calendar.getlnstance(); 

Instance  reportingData  =  updateReportingData(now); 

Instance  actionTaskStatus  =  updateActionTaskStatus(PLAN_ATS_CC); 

Instance  oaa  =  updateOAA(now); 

try  { 

_gh5KB.setStringSlot(oaa,  "intentText",  "We  intend  to  move  to  a  safe  location."); 

}  catch  (  StringLengthException  e  )  { 
throw  new  Error(e); 

} 

Instance  actionTask  =  updateActionTask(  "Withdraw", 

PLAN_AT_CC, 

MOVE_AT_VPC, 

"We  shall  move  to  a  safe  location  in  response  to  the  threat  from  "  + 
_gh5KB.getObjectltemName(_threat)  + 

_gh5KB.setDateSlot(actionTask,  "plannedStartDate",  now); 

establishRelations(_us,  _us,  reportingData,  actionTask,  actionTaskStatus,  oaa); 

return  collectedEntities(reportingData,  actionTask,  actionTaskStatus,  oaa); 

} 

} 
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6.8.  Class  SupportThreatenedOrg 

The  SupportThreatenedOrg  class  is  one  possible  course  of  action  in  response  to  a  threat.  The  functionality  in  this  class  evaluates 
whether  abandoning  one’s  current  objectives  to  provide  support  to  the  threatened  organization  is  an  appropriate  course  of  action.  As¬ 
sessing  appropriateness  of  this  course  of  action  includes  determining  whether  the  organization  evaluating  the  course  of  action  has 
other  objectives.  In  a  production  system  the  designers  would  want  to  weigh  the  feasibility  of  summarily  changing  those  objectives;  the 
IDA  prototype  currently  does  not  implement  this  functionality. 

package  ida.bh.cro.friendlyorg. threat. response; 

import  java. util. Calendar; 
import  java. util. List; 

import  ida.sd.gh5ontology.GH5KB; 

import  ida.sd.gh5ontology.StringLengthException; 

import  ida.sd. ontology. Instance; 

public  class  SupportThreatenedOrg 
extends  CourseOfAction  { 

I** 

*  Constructs  a  <code>SupportThreatenedOrg</code>  which  will  evaluate  the  effectiveness  of  us  supporting  a  threatened  organisation. 

*  @param  us  The  organisation  that  is  evaluating  whether  requesting  permission  to  withdraw  is  an  effective  course  of  action. 

*  @param  threatened  An  organisation  that  has  been  determined  to  be  threatened. 

*  @param  threat  An  organisation  that  threatens  <code>org</code>. 

**  j 

public  SupportThreatenedOrg(GH5KB  gh5KB,  Instance  us,  Instance  threatened,  Instance  threat)  { 
super(gh5KB,  us,  threatened,  threat); 

if  ( _gh5KB.getObjectltemName(_us).equals(_threatenedOrgName) )  { 

rationale. addf'We  are  the  threatened  organisation  and  so  can't  support  ourselves."); 

_value  =  O.Of; 

return; 

} 

_rationale. addf'We  are  not  the  threatened  organisation."); 
if  ( _gh5KB.commands(_us,  -threatened) )  { 

_rationale. addf'We  command  the  threatened  organisation  and  can't  provide  direct  support."); 

_value  =  O.Of; 

return; 

} 

-rationale. addf'We  don't  command  the  threatened  organisation."); 


C-114 


Instance  currentTask  =  _gh5KB.currentTask(_us); 
if  (  currentTask  !=  null )  { 

_rationale.add("We  are  otherwise  tasked."); 

_value  =  O.Of; 

return; 

} 

_rationale.add("We  are  not  otherwise  tasked."); 

double  supplyAdequacy  =  _gh5KB.supplyAdequacy(_us); 
if  (  supplyAdequacy  <  0.8  )  { 

_rationale.add("Our  supplies  are  inadequate."); 

_value  =  (float)supplyAdequacy; 

return; 

} 

_rationale.add("Our  supplies  are  adequate."); 

Instance  location  =  _gh5KB.getCurrentLocation(_threatened); 
if  ( location  ==  null )  { 

_rationale.add("Location  of "  +  _threatenedOrgName  +  "  can't  be  determined."); 

_value  =  O.Of; 

return; 

} 

try  { 

_value  *=  1  .Of  -  timingRatio(_us,  location,  true); 

return; 

}  catch  ( IncomputableException  e  )  { 

_value  =  O.Of; 

return; 

} 

} 

public  String  description()  { 

return  "We  provide  direct  support  to  "  +  _threatenedOrgName; 

} 

jit* 

*  Creates  the  list  of  C4I  entities  that  reflect  a  request  to  support  a  friendly  organisation  identified  as  threatened.  This  is  formulated  as 

*  a  plan  to  move. 

*  @return  The  list  of  C4I  entities  that  reflect  the  request. 

**  j 
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public  List  asC4IModel()  { 

Calendar  now  =  Calendar.getlnstance(); 

Instance  reportingData  =  updateReportingData(now); 

Instance  actionTaskStatus  =  updateActionTaskStatus(PLAN_ATS_CC); 

Instance  oaa  =  updateOAA(now); 

try  { 

_gh5KB.setStringSlot(oaa,  "intentText",  "We  intend  to  support "  +  _threatenedOrgName); 

}  catch  (  StringLengthException  e  )  { 
throw  new  Error(e); 

} 

Instance  actionTask  =  updateActionTask(  "Support", 

PLAN_AT_CC, 

MOVE_AT_VPC, 

"We  shall  request  to  support "  + 

_threatenedOrgName  + 

"  in  response  to  the  threat  from  "  + 

_gh5KB.getObjectltemName(_threat)  + 

ll.llj, 

establishRelations(_us,  _us,  reportingData,  actionTask,  actionTaskStatus,  oaa); 
return  collectedEntities(reportingData,  actionTask,  actionTaskStatus,  oaa); 

} 

} 

6.9.  Class  ThreatResponseNotification 

The  ThreatResponseNotification  class  is  a  data  abstraction  for  passing  a  set  of  courses  of  action  between  classes, 
package  ida.bh.cro.friendlyorg. threat. response; 
import  java. util. List; 

jit* 

*  The  <code>ThreatResponseNotification</code>  class  encapsulates  candidate  courses  of  action  in  response  to  a  threat.  The  primary  secret  of 

*  this  class  is  the  algorithms  and  data  structures  used  to  package  the  CoAs. 

**/ 

public  class  ThreatResponseNotification  { 

private  CourseOfActionf]  _prioritizedCoursesOfAction; 

private  String  _threatStatement; 


C-116 


I** 

*  Constructs  a  <code>ThreatResponseNotification</code>  based  on  a  prioritized  list  of 

*  {@link  ida.bh.cro.friendlyorg.threat.response.CourseOfAction  CourseOfAction}  instances. 

*  @param  threatStatement  A  textual  statement  of  the  threat. 

*  @param  prioritizedCoursesOfAction  Course  of  action,  from  highest  priority  to  lowest  priority. 

*  @todo  The  threat  statement  should  not  be  textual.  Expect  it  to  change  to  a  data  structure  of  some  sort. 

**  j 

public  ThreatResponseNotification(String  threatStatement,  List  prioritizedCoursesOfAction)  { 
_threatStatement  =  threatStatement; 
int  nCoAs  =  prioritizedCoursesOfAction. size(); 

_prioritizedCoursesOfAction  =  new  CourseOfAction[nCoAs]; 
for  ( int  i  =  0;  i  <  nCoAs;  i++  ) 

_prioritizedCoursesOfAction[i]  =  (CourseOfAction)prioritizedCoursesOfAction.get(i); 

} 

I** 

*  Gets  a  textual  statement  of  the  threat  associated  with  this  threat  response  notification. 

*  @return  A  textual  statement  of  the  threat. 

**  j 

public  String  threatStatement()  { 
return  _threatStatement; 

} 

I** 

*  Determines  if  this  <code>ThreatResponseNotification</code>  has  a  possible  course  of  action. 

*  @return  True  if  at  least  one  course  of  action  is  possible  (i.e. ,  has  a  value  &gt;0),  false  if  not. 

**  j 

public  boolean  hasPossibleCoA()  { 
return  possibleCoASize()  >  0; 

} 

j ** 

*  Gets  the  number  of  courses  of  action  associated  with  this  instance. 

*  @return  The  number  of  courses  of  action  associated  with  this  instance. 

**  j 

public  int  size()  { 

return  _prioritizedCoursesOfAction. length; 

} 

j ** 

*  Gets  the  number  of  <em>possible</em>  courses  of  action  associated  with  this  instance. 
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*  @return  The  number  of  possible  courses  of  action  associated  with  this  instance. 

**  j 

public  int  possibleCoASize()  { 

for  ( int  i  =  _prioritizedCoursesOfAction. length  - 1 ;  i  >=  0;  i —  )  { 
if  ( _prioritizedCoursesOfAction[i].value()  >  0.0  ) 

return  i  +  1; 

} 

return  0; 

} 

I** 

*  Gets  the  <i>i</i>'th  {@link  CourseOfAction}  associated  with  this  instance.  The  courses  of  action  are  in  priority  order,  from  highest  to  lowest. 

*  @return  The  <i>i</i>'th  {@link  CourseOfAction}  associated  with  this  instance. 

**  j 

public  CourseOfAction  get(int  i) 

throws  IndexOutOfBoundsException  { 

if  ( i  <  0  ||  i  >=  _prioritizedCoursesOfAction. length  ) 

throw  new  lndexOutOfBoundsException(new  lnteger(i).toString()); 
return  _prioritizedCoursesOfAction[i]; 

} 

I** 

*  Overrides  the  {@link  java.lang.Object#equals}  method  to  base  equality  on  comparison  of  the  {@linkplain  #threatStatement  threat  statement}. 

*  @param  o  The  object  to  be  tested  for  equality.  Should  be  a  <code>ThreatResponseNotification</code>. 

*  @return  <code>False</code>  if  <code>o</code>  is  not  a  <code>ThreatResponseNotification</code>; 

*  otherwise,  the  result  of  testing  equality  of  this  instance's  threat  statement  with  that  of  <code>o</code>'s. 

**  j 

public  boolean  equals(Object  o)  { 

ThreatResponseNotification  trn; 

try  { 

trn  =  (ThreatResponseNotification)o; 

}  catch  ( java.Iang.ClassCastException  e  )  { 

//  o  wasn't  a  ThreatResponseNotification. 
return  false; 

} 

try  { 

return  _threatStatement.equals(trn.threatStatement()); 

}  catch  ( java.Iang.NullPointerException  e  )  { 

//  _threatStatement  was  null, 
return  trn.threatStatement()  ==  null; 
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} 

} 

I** 

*  Overrides  {@link  java.lang.Object#hashCode}  consistent  with  the  overridden  definition  of  {@linkplain  #equals  equality}  for  this  class. 

*  @return  The  hash  code  for  the  {@linkplain  #threatStatement  threat  statement}. 

**  j 

public  int  hashCode()  { 

return  _threatStatement.hashCode(); 

} 

} 

6. 10.  Class  ThreatStmtContext 

The  ThreatStmtContext  class  implements  a  context  in  which  SLO  content  can  be  evaluated.  The  ontology  used  to  send  threat  statements 
has  two  predicates,  threat  and  not-threat.  This  class  provides  methods  that  implement  each. 

package  ida.bh.cro.friendlyorg. threat. response; 

import  fipaos.ont.fipa.ACL; 

import  fipaos.ont.fipa.FIPACONSTANTS; 

import  ida.sd.FIPA.slO.SLO; 

I** 

*  Class  <code>ThreatStmtContext</code>  implements  a  {@link  ida.sd.FIPA.slO.SLO. Context  Context}  that  provides  two  predicates: 

*  <code>(threat&nbsp;org-1  &nbsp;org-2)</code>  and  <code>(not-threat&nbsp;org-1  &nbsp;org-2)</code>. 

*  Using  SL1  would  be  preferrable.  Oh  well,  as  soon  as  it's  implemented.... 

**  j 

public  class  ThreatStmtContext 
implements  SLO. Context  { 

/**  The  ACL  for  this  instance.  7 

private  ACL  _acl; 

/**  The  IdleTask  instance  that  creates  this  instance.  7 
private  IdleTask  task; 

j ** 

*  Constructs  a  <code>ThreatStmtContext</code>. 

*  @param  acl  An  ACL  for  this  instance. 

*  @param  task  The  {@link  IdleTask}  instance  that  creates  this  instance. 

**  j 
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public  ThreatStmtContext(ACL  acl,  IdleTask  task)  { 

_acl  =  acl; 

_task  =  task; 

} 

I** 

*  Implements  the  <code>threat</code>  predicate,  which  states  that  one  organisation  is  a  threat  to  another  organisation. 

*  @param  threatener  The  name  of  the  organisation  that's  a  threat. 

*  @param  threatened  The  name  of  the  organisation  that's  threatened  by  <code>threatener</code>. 

*  @return  True. 

**  j 

public  Boolean  threat(String  threatener,  String  threatened)  { 

if  ( _acl.getPerformative().equalslgnoreCase(FIPACONSTANTS. INFORM) ) 

_task.respondToThreat(threatener,  threatened); 

return  new  Boolean(true); 

} 

I** 

*  Implements  the  <code>not-threat</code>  predicate,  which  states  that  one  organisation  (the  subject)  is  <em>not</em>  a  threat  to  another 

*  organisation  (the  object). 

*  @param  subjectOrg  The  subject  organisation's  name. 

*  @param  objectOrg  The  object  organisation's  name. 

*  @return  True. 

**  j 

public  Boolean  notThreat(String  subjectOrg,  String  objectOrg)  { 

if  ( _acl.getPerformative().equalslgnoreCase(FIPACONSTANTS. INFORM) ) 

_task.respondToThreatCancellation(subjectOrg,  objectOrg); 

return  new  Boolean(true); 

} 

//  The  methods  to  implement  the  context  are  trivial,  since  this  context  has  no  functions  and  doesn't  expect  a  result, 
private  final  static  String  eMsg  =  "Unimplemented  context  facet"; 

j ** 

*  Throws  an  {@link  java. lang. Error}  indicating  this  method  shouldn't  be  invoked. 

*  @throws  Error  If  this  method  is  invoked. 

**  j 

public  Boolean  evaluateResult(Object  term,  Object  equivalentTerm)  { 
throw  new  Error(eMsg); 
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I** 

*  Throws  an  {@link  java. lang. Error}  indicating  this  method  shouldn't  be  invoked. 

*  @throws  Error  If  this  method  is  invoked. 

**  j 

public  String}]  getFunctionParams(String  functionName)  { 
throw  new  Error(eMsg); 

} 

I** 

*  Throws  an  {@link  java. lang. Error}  indicating  this  method  shouldn't  be  invoked. 

*  @throws  Error  If  this  method  is  invoked. 

**  j 

public  Boolean  truth(Boolean  truth)  { 
throw  new  Error(eMsg); 

} 
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Annex  D:  GH5  Ontology  Implementation 

This  annex  presents  the  implementation  of  the  GH5  Ontology  component  of  the  prototype. 
The  GH5  Ontology  component  encapsulates  many  important  design  decisions  regarding  how 
other  components  access  a  GH  knowledge  base. 

Annex  B  gives  a  high-level  view  of  the  GH5  Ontology  component’s  design.  This  annex 
complements  Annex  B  with  detailed  design  and  implementation  information.  Annex  B 
breaks  components  down  into  packages.  This  annex  continues  with  classes  and  their  con¬ 
tents. 


1.  Package  and  Class  Structure 

The  GH5  Ontology  consists  of  a  single  package  named  gh5ontology.  Figure  1  shows  the  outer 
classes  in  the  package.  The  package  has  three  kinds  of  classes: 

1 .  Classes  in  the  top  group  provide  the  package’s  behavior. 

2.  Classes  in  the  lower  left  group  are  the  exceptions  thrown  by  methods  in  the  package. 

3.  Classes  in  the  lower  right  are  the  errors  thrown  by  methods  in  the  package.  It  is  not 
common  practice  to  throw  errors  rather  than  exceptions  in  Java  programs.  The  IDA 
prototype  simulation  does  so  in  response  to  mistakes  in  external  definitions,  in  par¬ 
ticular  those  in  the  GH  ontology.  If  one  of  these  errors  is  thrown,  it  indicates  that  the 
ontology  needs  to  be  fixed  before  the  prototype  can  execute  correctly.  The  expecta¬ 
tion,  of  course,  is  that  these  errors  will  never  be  thrown. 

The  five  classes  in  the  top  group  may  be  further  categorized.  Class  GH5KB  is  the  main  class 
of  the  package,  providing  most  of  the  functionality.  The  other  classes  encapsulate  some  por¬ 
tion  of  ontology  behavior: 

•  Class  DateTime  encapsulates  how  the  GH  Ontology  represents  dates  and  times,  trans¬ 
lating  betweens  these  representations  and  Java  standard  classes. 

•  Class  NumericExpression  encapsulates  the  Numeric-Expression  ontology. 

•  Class  ReportingData  encapsulates  the  GH  Ontology  notion  of  the  ReportingData  class, 
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Figure  1.  Friendly  Organization  Component  Package  and  Class  Structure 
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particularly  with  regard  to  ordering  a  set  of  instances  of  reporting  data  by  some  crite¬ 
rion.  The  class  is  supported  by  the  two  classes  RDComparator  and  RDEComparator, 
which  implement  comparisons  of  two  instances  of  ReportingData  according  to  report¬ 
ing  date/time  and  effective  date/time,  respectively. 

1.  Documentation  Conventions 

The  code  for  the  prototype  is  documented  according  to  the  conventions  for  the  javadoc  tool. 
These  conventions  help  to  standardize  the  content  and  format  of  API  documentation.  See 
http://iava.sun.eom/i2se/l.4.2/docs/tooldocs/iavadoc/  for  more  information. 

Javadoc  translates  comments  of  the  form  /*  ...  */  into  input  to  an  HTML  interpreter.  These 
comments  often  contain  HTML  elements.  The  translated  version,  viewed  in  a  browser,  is 
generally  easier  to  comprehend.  The  HTML  versions  are  included  on  the  CD  that  accompa¬ 
nies  this  document. 

The  IDA  prototype  simulation  adds  one  non-standard  javadoc  tag:  “@todo”.  This  tag  indi¬ 
cates  an  aspect  of  functionality  needed  in  a  production  system  but  beyond  the  scope  of  the 
current  prototype. 
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2.  Class  GH5KB 

The  GH5KB  class  is  the  main  class  of  the  gh5ontology  package.  The  FriendlyOrg  class  (Annex  C)  creates  an  instance  of  GH5KB.  It  uses 
this  instance  to  access  a  knowledge  base  instead  of  directly  accessing  the  prototype’s  underlying  model  of  a  knowledge  base  in  pack¬ 
age  ida.sd. ontology  (Annex  B,  Section  3.6.2)  or  the  Protege-2000  implementation  beneath  that  model.  Indeed,  the  instance  of  GH5KB  is 
the  knowledge  base  so  far  as  a  FriendlyOrg  is  concerned. 

Class  GH5KB  implements  interface  ida.sd. ontology. KnowledgeBase  and  so  provides  all  the  operations  expected  of  a  knowledge  base  in 
the  context  of  the  IDA  prototype.  However,  class  GFI5KB  has  some  knowledge  of  the  structure  of  a  GH  ontology,  in  particular  how  slot 
values  are  represented.  Instance  methods  of  the  class  translate  Java  types  (e.g.,  int,  float)  and  classes  (e . g . ,  String,  Calendar)  into  values 
appropriate  to  the  slots,  namely  the  GH  ontology’s  type-instance-value  format  (Annex  A).  Note  that  some  facets  of  slots  -  their  names 
and  cardinality,  for  instance  -  are  not  encapsulated  by  the  class.  A  friendly  organization  must  understand  the  ontology  to  a  certain  de¬ 
gree. 

Class  GFI5KB  also  contains  some  methods  that  encapsulate  procedural  abstractions.  Examples  include  inPathOfQ,  which  detennines 
whether  a  moving  object  is  on  a  linear  path  that  intersects  the  area  near  a  specified  point,  and  isHostile(),  which  tests  whether  a  battle¬ 
field  object  is  hostile  to  a  friendly  organization.  Including  these  methods  in  the  class  standardizes  the  meaning  of  concepts  such  as 
hostility.  Arguably,  these  methods  belong  in  distinct  classes  within  the  gh5ontology  package,  as  the  concepts  they  encapsulate  are  dis¬ 
tinct. 

package  ida.sd. gh5ontology; 

import  java. text. SimpleDateFormat; 

import  java. util. Calendar; 
import  java. util. Collection; 
import  java. util. Collections; 
import  java. util. HashMap; 
import  java. util. HashSet; 
import  java. util. Iterator; 
import  java. util. LinkedList; 
import  java. util. List; 
import  java. util. Map; 
import  java. util. Set; 

import  ida.sd. Earth; 
import  ida.sd. ontology.*; 

import  ida.sd. ontology. impl. protege. ProtegeProject; 
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import  ida.sd.osb.BindingException; 
import  ida.sd.osb.BindingPA; 
import  ida.sd.Track; 

import  ida.sd. Diagnostics; 

I** 

*  Class  <code>GH5KB</code>  implements  a  {@link  ida.sd. ontology.KnowledgeBase}  specific  to  the  GH5.  It  extends  the  canonical  set  of 

*  methods  for  accessing  a  knowledge  base  with  methods  specific  to  the  structure  of  the  GH5,  as  well  as  useful  procedural  abstractions. 

*  <p>The  primary  secrets  of  this  class  are  the  representation  of  slot  values  in  the  GH5,  and  the  algorithms  used  to  implement  access  methods. 

**  i 

public  class  GH5KB 

implements  KnowledgeBase  { 

private  final  static  int  ORG  TRACK  SIZE  =  50; 

private  final  static  double  OBJ_HALF_WIDTH  =  (ORG_TRACK_SIZE/2.0)/Earth.METERS_PER_DEGREE; 

/**  The  underlying  {@link  ida.sd.ontology. KnowledgeBase}.  */ 
private  KnowledgeBase  kb; 

//  The  following  fields  are  ontology  elements  that  are  accessed  in  many  methods,  and  are  therefore  initialized  and  maintained  to  prevent  having 

//  to  look  them  up  repeatedly. 

private  final  CIs  _numericExpressionCls; 

private  final  CIs  _fixedLengthStringCls; 

private  final  CIs  objltemCIs; 

private  final  CIs  orgCIs; 

private  final  CIs  mobilityCapabilityCIs; 

private  final  Slot  nameSlot; 
private  final  Slot_objlteml_ocSlot; 
private  final  Slot  objltemLocRDRefSIot; 

private  final  Slot  tivSIot; 
private  final  Slot  eelSIot; 

private  final  Slot_stringLengthSlot; 

private  final  NumericExpression  _numericExpression; 

jit* 

*  Constructs  a  GH5KB  that  is  a  wrapper  around  a  {@link  ida.sd. ontology. KnowledgeBase}  that  models  the  GH5.  No  formal  check  is  made  as 

*  to  whether  the  knowledge  base  models  the  GH5,  but  if  it  doesn't  attempts  to  use  the  instance  will  quickly  yield  exceptions. 

*  @param  kb  A  <code>KnowledgeBase</code>  that  models  the  GH5. 

**  j 

public  GH5KB(KnowledgeBase  kb)  { 
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kb  =  kb; 

_numericExpressionCls  =  _kb.getCls("Numeric-Expression"); 

_fixedl_engthStringCls  =  _kb.getCls("String-Type-Fixed"); 

mobilityCapabilityCIs  =  kb.getCls("MobilityCapability"); 

_objltemCls  =  kb.getCls("Objectltem"); 

_orgCls  =  kb.getCls("Organisation"); 

tivSIot  =  kb.getSlot("type-instance-value"); 

_nameSlot  =  kb.getSlot("name"); 

_objltemLocRDRefSlot  =  kb.getSlot("obj_item_loc-is-referenced-to-ReportingData"); 

_objltemLocSlot  =  kb.getSlot("is-geometrically-defined-through-ObjectltemLocation"); 

_eelSlot  =  _kb.getSlot("enumerated-element-label"); 

_stringLengthSlot  =  _kb.getSlot("textual-class-string-length"); 

_numericExpression  =  new  NumericExpression(kb); 

} 

I** 

*  Returns  the  named  {@link  ida.sd.ontology.CIs}. 

*  @param  name  The  name  of  a  <code>Cls</code>  in  the  GH5  ontology. 

*  @return  The  named  {@link  ida.sd.ontology.CIs}. 

**  j 

public  CIs  getCls(String  name)  { 
return  _kb.getCls(name); 

} 

I** 

*  Returns  the  named  {@link  ida.sd. ontology. Slot}. 

*  @param  name  The  name  of  a  <code>Slot</code>  in  the  GH5  ontology. 

*  @return  The  named  {@link  ida.sd. ontology. Slot}. 

**  j 

public  Slot  getSlot(String  name)  { 
return  _kb.getSlot(name); 

} 

j ** 

*  Returns  the  named  {@link  ida.sd. ontology. Instance}. 

*  @param  name  The  name  of  an  <code>lnstance</code>  in  the  GH5  knowledge  base. 

*  @return  The  named  {@link  ida.sd. ontology. Instance}. 

**  j 
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public  Instance  getlnstance(String  name)  { 
return  _kb.getlnstance(name); 

} 

I** 

*  Deletes  an  {@link  ida.sd.ontology. Instance}  from  the  knowledge  base. 

*  @param  inst  The  instance  to  delete  from  the  knowledge  base. 

**  j 

public  void  deletelnstance(lnstance  inst)  { 

_kb.deletelnstance(inst); 

} 

jit* 

*  Returns  an  {@link  ida.sd.ontology. Instance}  of  an  <code>Objectltem</code>  as  identified  by  its  <code>name</code> 

*  {@link  ida.sd.ontology. Slot}.  If  multiple  <code>Objectltem</code>s  have  the  same  name,  this  method  randomly  chooses  one. 

*  @param  name  A  string. 

*  @return  An  {@link  ida.sd.ontology. Instance}  of  an  <code>Objectltem</code>  whose  name  slot  has  the  value  <code>name</code>, 

*  or  <code>null</code>  if  no  such  <code>lnstance</code>  exists. 

**  j 

public  Instance  getObjectltem(String  name)  { 
return  getBattlefieldObject(_objltemCls,  name); 

} 

j ** 

*  Returns  an  {@link  ida.sd.ontology. Instance}  of  a  {@link  ida.sd.ontology. CIs}  (including  its  subclasses)  with  a  <code>name</code> 

*  {@link  ida.sd.ontology. Slot}  where  the  value  of  the  <code>name</code>  slot  matches  a  given  string.  If  multiple  <code>Objectltem</code>s 

*  have  the  same  name,  this  method  randomly  chooses  one. 

*  @param  els  A  {@link  ida.sd.ontology. CIs}  with  a  <code>name</code>  slot. 

*  @param  name  A  string. 

*  @return  An  {@link  ida.sd.ontology. Instance}  of  <code>cls</code>  whose  name  slot  has  the  value  <code>name</code>, 

*  or  <code>null</code>  if  no  such  <code>lnstance</code>  exists. 

**  j 

public  Instance  getBattlefieldObject(Cls  els,  String  name)  { 

if  ( !  (cls.equals(_objltemCls)  ||  cls.hasSuperclass(_objltemCls) ) ) 
throw  new  lnvalidClsError(_objltemCls,  els); 

for  ( Iterator  oilter  =  cls.getlnstances().iterator();  oilter.hasNext();  )  { 

Instance  oilnst  =  (lnstance)oilter.next(); 
if  (  name.equals(getStringSlot(oilnst,  _nameSlot)) ) 
return  oilnst; 

} 
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return  null; 


} 

I** 

*  Returns  the  value  of  the  <code>name</code>  {@link  ida.sd.ontology.Slot}  of  an  {@link  ida.sd. ontology. Instance}  of 

*  <code>Objectltem</code>  or  one  of  its  subclasses.  Throws  an  error  if  the  given  instance  isn't  of  the  correct  <code>cls</code>. 

*  @param  objltem  A  direct  or  indirect  instance  of  <code>Objectltem</code>. 

*  @return  The  value  of  the  <code>name</code>  slot  of  <code>objltem</code>. 

**  j 

public  String  getObjectltemName(lnstance  objltem)  { 
if  ( !  objltem. instanceOf(_objltemCls) ) 

throw  new  lnvalidClsError(_objltemCls,  objltem. getDirectType()); 
return  getStringSlot(objltem,  "name"); 

} 

I** 

*  Returns  all  direct  and  indirect  instances  of  the  <code>Objectltem</code>  {@linkplain  ida.sd. ontology. CIs  class}. 

*  @return  All  direct  and  indirect  instances  of  the  <code>Objectltem</code>  {@linkplain  ida.sd. ontology. CIs  class}. 

**  j 

public  Collection  getBattlefieldObjects()  { 
return  _objltemCls.getlnstances(); 

} 

j ** 

*  Returns  the  current  (i.e.,  most  recent  according  to  <code>ReportingData</code>)  location  of  an  <code>Objectltem</code> 

*  {@linkplain  ida.sd. ontology. Instance  instance}. 

*  @param  objectltem  An  instance  of  the  <code>Objectltem</code>  class. 

*  @return  The  {@linkplain  ida.sd. ontology. Instance  instance}  of  <code>Location</code>  associated  with  <code>objectltem</code>  that  has 

*  the  most  recent  reporting  date,  or  <code>null</code>  if  no  instances  of  <code>Location</code>  are  associated  with 

*  <code>Objectltem</code>. 

**  j 

public  Instance  getCurrentLocation(lnstance  objectltem)  { 
if  ( !  objectltem. instanceOf(_objltemCls) ) 

throw  new  lnvalidClsError(_objltemCls,  objectltem.getDirectType()); 

Instance  mostRecentObjltemLoc  =  ReportingData.getMostRecent(this, 

objectltem.  getOwnSlotValues(_objltemLocSlot), 
_objlteml_ocRDRefSlot); 

if  (  mostRecentObjltemLoc  ==  null ) 
return  null; 
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return  (lnstance)mostRecentObjltemLoc.getOwnSlotValue(_kb.getSlot("obj_item_loc-is-associated-with-Location")); 

} 

I** 

*  Returns  true  if  one  battlefield  object  {@link  ida.sd. ontology. Instance  instance}  is  moving  such  that  its  track  intersects  the  location  of  another 

*  {@link  ida.sd. ontology. Instance  instance}.  The  second  instance  is  assumed  not  to  be  moving. 

*  <p>Currently,  each  instance  is  assumed  to  be  ORG_TRACK_SIZE  metres  wide.  The  moving  object's  tract  intersects  the  static  object's  track 

*  if  there's  any  overlap. 

*  @param  movingObj  The  {@link  ida.sd. ontology. Instance}  that's  moving. 

*  @param  staticObj  The  {@link  ida.sd. ontology. Instance}  at  rest. 

**  j 

public  boolean  inPathOf(lnstance  movingObj,  Instance  staticObj) 
throws  NoLocationException,  SpeedlndeterminateException  { 
if  ( !  movingObj. instanceOf(_objltemCls) ) 

throw  new  lnvalidClsError(_objltemCls,  movingObj.getDirectType()); 
if  ( !  staticObj. instanceOf(_objltemCls) ) 

throw  new  lnvalidClsError(_objltemCls,  staticObj .getDirectType()); 

List  objltemLocations; 
int  size; 

objltemLocations  =  new  LinkedList(movingObj.getOwnSlotValues(_objltemLocSlot)); 

II  If  movingObj  doesn't  have  any  location  information,  we  can't  determine  its  path, 
if  ( (size  =  objltemLocations. size())  ==  0  ) 

throw  new  NoLocationException(getObjectltemName(movingObj)); 

Instance  mostRecentObjltemLoc  =  ReportingData.getMostRecent(this,  objltemLocations,  _objltemLocRDRefSlot); 

double  latCur; 
double  lonCur; 

Slot  locSIot  =  _kb.getSlot("obj_item_loc-is-associated-with-Location"); 

II  Get  the  current  location  of  the  staticObj. 

Instance  staticObjectltemLoc  =  getCurrentLocation(staticObj); 

double  staticObjectltemLatitude  =  getFloatSlot(staticObjectltemLoc,  "latitudeCoordinate").doubleValue(); 
double  staticObjectltemLongitude  =  getFloatSlot(staticObjectltemLoc,  "longitudeCoordinate").doubleValue(); 

//  First,  see  if  the  ObjectltemLocation  has  a  bearing  angle.  If  so,  use  it. 

Instance  bearingAnglelnst  =  (lnstance)mostRecentObjltemLoc.getOwnSlotValue(_kb.getSlot("bearingAngle")); 
if  (  bearingAnglelnst  !=  null )  { 

Instance  numericExpr  =  (lnstance)bearingAnglelnst.getOwnSlotValue(_tivSlot); 

double  bearingAngle  =  ((Float)_numericExpression.evaluate(numericExpr)).doubleValue(); 

Instance  movingLoc  =  (Instance)mostRecentObjltemLoc.getOwnSlotValue(locSlot); 
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latCur  =  getFloatSlot(movingLoc,  "latitudeCoordinate").doubleValue(); 
lonCur  =  getFloatSlot(movingLoc,  "longitudeCoordinate").doubleValue(); 

return  Track.overlaps(lonCur,  latCur,  bearingAngle,  staticObjectltemLongitude,  staticObjectltemLatitude,  OBJ_HALF_WIDTH); 

} 

else  { 

II  Use  the  last  two  objltemLocations,  and  extrapolate, 
if  (  size  ==  1  ) 

throw  new  Speed lndeterminateException(getObjectltemName(movingObj)); 

ReportingData.sortByReportingTime(this,  objltemLocations,  _objltemLocRDRefSlot); 


//  Get  the  last  two  points  in  the  list,  and  extrapolate, 
double  latPrev,  lonPrev; 

Instance  objltemLoc,  loc; 

loc  =  (lnstance)((lnstance)objltemLocations.get(size  -  2)).getOwnSlotValue(locSlot); 
latPrev  =  getFloatSlot(loc,  "latitudeCoordinate").doubleValue(); 
lonPrev  =  getFloatSlot(loc,  "longitudeCoordinate").doubleValue(); 

loc  =  (lnstance)((lnstance)objltemLocations.get(size  -  1)).getOwnSlotValue(locSlot); 
latCur  =  getFloatSlot(loc,  "latitudeCoordinate").doubleValue(); 
lonCur  =  getFloatSlot(loc,  "longitudeCoordinate").doubleValue(); 

double  distPrev  =  Earth. distance(latPrev,  lonPrev,  staticObjectltemLatitude,  staticObjectltemLongitude); 
double  distCur  =  Earth. distance(latCur,  lonCur,  staticObjectltemLatitude,  staticObjectltemLongitude); 

if  (  distPrev  <=  distCur )  //  Is  the  moving  object  coming  closer? 

return  false;  //  If  not,  return  false. 

if  ( lonCur  !=  lonPrev  )  { 

double  slope  =  (latCur  -  latPrev)/(lonCur  -  lonPrev); 
double  yjntercept  =  latPrev  -  slope*lonPrev; 

return  Track.overlaps(slope,  yjntercept,  staticObjectltemLongitude,  staticObjectltemLatitude,  OBJ_HALF_WIDTH); 

} 

else  { 

return  Track.overlaps(lonCur,  latCur,  0.0,  staticObjectltemLongitude,  staticObjectltemLatitude,  OBJ_HALF_WIDTH); 

} 

} 

} 

jit* 


II  Only  1  location. 

//  Sorts  on  reportingDate/reportingTime; 

//  arguably,  effectiveDate/effectiveTime  is 
//  what's  wanted. 
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*  Determines  whether  an  {@linkplain  ida.sd. ontology. Instance  instance}  of  an  <code>Objectltem</code>  is  hostile.  Hostility  is 

*  specified  by  the  hostility  code  associated  with  the  <code>Objectltem</code>'s  most  recent  <code>ObjectltemStatus</code>  instance. 

*  If  the  <code>Objectltem</code>  has  no  status,  it  is  assumed  to  be  hostile. 

*  @param  oi  The  <code>Objectltem</code>  whose  hostility  is  to  be  determined. 

*  @return  True  if  the  <code>Objectltem</code>  is  hostile,  false  if  not. 

**  j 

public  boolean  isHostile(lnstance  objltem)  { 
if  ( !  objltem. instanceOf(_objltemCls) ) 

throw  new  lnvalidClsError(_objltemCls,  objltem. getDirectType()); 

Instance  mostRecentStatus  =  ReportingData.getMostRecent(this, 

objltem.  getOwnSlotValues(_kb.getSlot("has-ObjectltemStatus")), 
_kb.getSlot("obj-item-status-is-referenced-to-ReportingData")); 

if  (  mostRecentStatus  ==  null ) 
return  true; 

String  hostilityCode  =  getCodeSlot(mostRecentStatus,  "hostilityCode"); 
return  hostilityCode  ==  null  ||  hostilityCode. equals("HO"); 

} 

jit* 

*  Determines  the  time  needed  for  an  organisation  to  reach  a  location.  Works  by  first  checking  mobility  capability.  If  the  organisation 

*  has  none,  checks  past  movement  history  to  determine  maximum  speed.  If  there's  no  movement  history,  throws  an  exception. 

*  @param  org  The  organisation  whose  capability  to  move  is  to  be  determined. 

*  @param  destination  The  location  to  which  we  might  like  the  organisation  to  move. 

*  @return  The  estimated  duration,  in  seconds,  needed  for  the  the  organisation  to  move  from  its  current  location  to  the  destination. 

*  @throws  NoLocationException  If  the  organisation  has  no  current  location. 

*  @throws  SpeedlndeterminateException  If  the  organisation's  speed  can't  be  estimated. 

**  j 

public  synchronized  Double  estimatedTimeToReach(lnstance  org,  Instance  destination) 
throws  NoLocationException, 

SpeedlndeterminateException  { 

double  orgSpeed;  //  The  speed  at  which  the  organisation  can  travel,  in  km/hr. 

//  Check  org's  mobility  capabilities. 

List  mobilityCapabilities  =  new  LinkedList(); 

//  First  check  through  ObjectltemCapability. 

Collection  capabilities  =  org.getOwnSlotValues(_kb.getSlot("is-specified-with-ObjectltemCapability")); 
if  (  capabilities. size()  >  0  )  { 

extractMobilityCapabilities(capabilities,  mobilityCapabilities,  _kb.getSlot("obj-item-cap-quantifies-Capability")); 
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else  { 

//Try  through  ObjectTypeCapabilityNorm. 

Collection  objectltemTypes  =  org.getOwnSlotValues(_kb.getSlot("is-classified-as-ObjectltemType")); 
if  (  objectltemTypes. size()  >  0  )  { 

for  ( Iterator  oitlter  =  objectltemTypes. iterator();  oitlter.hasNext();  )  { 

Instance  objType  =  (lnstance)oitlter.next(); 

capabilities  =  objType.  getOwnSlotValues(_kb.getSlot("is-specified-as-having-ObjectTypeCapabilityNorm")); 
if  (  capabilities. size()  >  0  ) 

extractMobilityCapabilities(capabilities,  mobilityCapabilities,  _kb.getSlot("obj-type-cap-norm-quantifies-Capability")); 

} 

} 

} 

if  (  mobilityCapabilities. size()  >  0  )  { 

II  We  ignore  the  day/night  codes,  terrain  attributes,  etc.  for  now. 
orgSpeed  =  0.0; 

for  ( Iterator  clter  =  mobilityCapabilities. iterator();  clter.hasNext();  )  { 

Instance  capabilitySpecj]  =  (lnstance[])clter.next(); 

Instance  capabilityAssoc  =  (lnstance)capabilitySpec[Oj; 

Instance  mobilityCapability  =  (lnstance)capabilitySpec[1]; 

double  quantity  =  getFloatSlot(capabilityAssoc,  "quantity").doubleValue(); 

String  UoM  =  getCodeSlot(mobilityCapability,  "unitOfMeasureCode"); 
if  (  !  UoM.equals(”KPH")  ) 

throw  new  Error("Not  prepared  to  deal  with  unit "  +  UoM); 
if  (  quantity  >  orgSpeed  ) 
orgSpeed  =  quantity; 

} 

} 

else  { 

//Try  through  movement  history. 

orgSpeed  =  battlefieldObjectSpeedThroughHistory(org); 

} 

if  (  orgSpeed  ==  0.0  ) 

throw  new  SpeedlndeterminateException(getObjectltemName(org)); 

Instance  currentLocation  =  getCurrentLocation(org); 

double  distanceToDestination  =  Earth. distance(getFloatSlot(currentLocation,  "latitudeCoordinate").doubleValue(), 

getFloatSlot(currentLocation,  "longitudeCoordinate").doubleValue(), 
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getFloatSlot(destination,  "latitudeCoordinate").doubleValue(), 
getFloatSlot(destination,  "longitudeCoordinate").doubleValue()); 
return  new  Double(3600.0  *  (distanceToDestination/1 000.0)/  orgSpeed); 

} 

I** 

*  Takes  a  {@link  java. util. Collection}  of  associative  entities  that  represent  associations  between  either  an  <code>Objectltem</code>  or 

*  an  <code>ObjectType</code>,  and  identifies  which  of  the  associative  entities  represent  mobility  capabilities.  For  each  mobility  capability, 

*  constructs  a  two-element  array  (<code>lnstance[2]</code>)  containing  the  associative  entity  and  the  related  mobility  capability. 

*  Each  such  array  is  added  to  the  <code>mobilityCapabilities</code>  parameter. 

*  @param  capabilityAssocs  A  homogeneous  collection  of  {@linkplain  ida.sd. ontology. Instance  instances} 

*  of  either  <code>ObjectltemCapability</code>  or  <code>ObjectTypeCapabilityNorm</code>. 

*  @param  mobilityCapabilities  A  {@link  java. util. List}  that,  on  return  from  this  method, 

*  will  have  all  mobility  capabilities  identified  from  <code>capabilityAssocs</code>  added. 

*  @param  assocSIot  A  {@link  ida.sd. ontology. Slot}  present  in  the  members  of  <code>capabilityAssocs</code>.  It  must  be  an  inverse  slot  of 

*  either  <code>is-quantified-in-ObjectltemCapability</code>  or  <code><code>is-quantified-in-ObjectTypeCapabilityNorm</code>. 

**  i 

private  void  extractMobilityCapabilities(Collection  capabilityAssocs,  List  mobilityCapabilities,  Slot  assocSIot)  { 
for  ( Iterator  calter  =  capabilityAssocs. iterator();  calter.hasNext();  )  { 

Instance  cAssoc  =  (lnstance)calter.next(); 

Instance  capability  =  (Instance)cAssoc.getOwnSlotValue(assocSlot); 
if  (  capability.getDirectType().equals(_mobilityCapabilityCls) ) 
mobilityCapabilities. add(new  Instance}]  {  cAssoc,  capability  }); 

} 

} 

I** 

*  Returns  the  speed  of  a  battlefield  object  as  determined  by  its  last  two  observed  locations. 

*  @param  battlefieldObject  The  object  whose  speed  is  to  be  computed. 

*  @return  The  speed  of  the  battlefield  object,  in  km/hr. 

*  @throws  NoLocationException  If  the  organisation  has  no  current  location. 

*  @throws  SpeedlndeterminateException  If  the  object  has  only  one  location,  or  if  the  locations  were  reported  at  the  same  time. 

*  @todo  Support  relative  reporting  data. 

**  i 

public  synchronized  double  battlefieldObjectSpeedThroughHistory(lnstance  battlefieldObject) 
throws  NoLocationException, 

SpeedlndeterminateException  { 

List  objltemLocationsList  =  new  LinkedList(battlefieldObject.getOwnSlotValues(_objltemLocSlot)); 

//  If  there's  no  location,  we  conclude  the  object  isn't  moving. 
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int  size  =  objltemLocationsList.size(); 
if  (  size  ==  0  ) 

throw  new  NoLocationException(getObjectltemName(battlefieldObject)); 

ReportingData.sortByReportingTime(this,  objltemLocationsList,  _objlteml_ocRDRefSlot); 

//  If  the  last  point  in  the  list  has  a  speed,  use  that. 

Instance  currentObjltemLocInst  =  (Instance)objltemLocationsList.get(size  - 1); 

Double  speed; 

if  ( (speed  =  getFloatSlot(currentObjlteml_oclnst,  "speedRate"))  !=  null ) 
return  speed. doubleValue(); 

//  If  the  list  has  only  1  item,  the  object  isn't  moving, 
if  (  size  ==  1  ) 

throw  new  Speed lndeterminateException(getStringSlot(battlefieldObject,  "name")); 

//  Use  the  last  2  points  to  compute  the  speed, 
double  prevLat,  prevLon; 
double  curLat,  curLon; 

String  date,  time; 

Instance  reportingData; 

Slot  oil2Location  =  _kb.getSlot("obj_item_loc-is-associated-with-Location"); 

Instance  prevObjltemLocInst  =  (Instance)objltemLocationsList.get(size  -  2); 

Instance  prevLocation  =  (lnstance)prevObjltemLoclnst.getOwnSlotValue(oil2Location); 
prevLat  =  getFloatSlot(prevLocation,  "latitudeCoordinate").doubleValue(); 
prevLon  =  getFloatSlot(prevLocation,  "longitudeCoordinate").doubleValue(); 

reportingData  =  (lnstance)prevObjltemLoclnst.getOwnSlotValue(_objltemLocRDRefSlot); 

//  The  following  assumes  reportingData  is  absolute. 

Calendar  prevTime  =  getDateTimeSlots(reportingData,  "effectiveDate",  "effectiveTime"); 
if  (  prevTime  ==  null ) 

throw  new  Speed lndeterminateException(getObjectltemName(battlefieldObject)); 

Instance  currentLocation  =  (lnstance)currentObjltemLoclnst.getOwnSlotValue(oil2Location); 
curLat  =  getFloatSlot(currentLocation,  "latitudeCoordinate").doubleValue(); 
curLon  =  getFloatSlot(currentLocation,  "longitudeCoordinate").doubleValue(); 

reportingData  =  (lnstance)currentObjltemLoclnst.getOwnSlotValue(_objltemLocRDRefSlot);  //  Should  check  to  see  if  it's  absolute 

//  or  relative... 

Calendar  curTime  =  getDateTimeSlots(reportingData,  "effectiveDate",  "effectiveTime");; 
if  (  curTime  ==  null ) 

throw  new  Speed lndeterminateException(getStringSlot(battlefieldObject,  "name")); 
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long  timeSpan  =  (curTime.getTime().getTime()  -  prevTime.getTime().getTime())/1000; 
if  ( timeSpan  ==  0  ) 

throw  new  Speed lndeterminateException(getStringSlot(battlefieldObject,  "name")); 

double  distance  =  Earth. distance(prevLat,  prevLon,  curLat,  curLon); 
return  (distance/timeSpan)*3.6;  //  3.6  multiplier  converts  m/s  to  km/hr. 

} 

I** 

*  A  {@link  java. util. Comparator}  suitable  for  comparing  two  {@linkplain  ida.sd. ontology. Instance  instances} 

*  that  have  <code>effectiveDate</code>  and  <code>effectiveTime</code>  slots. 

**  i 

public  final  java. util. Comparator  dtComparator  =  new  java. util. Comparator()  { 
public  int  compare(Object  ol ,  Object  o2)  { 

Calendar  cl  =  getDateTimeSlots((lnstance)o1,  "effectiveDate",  "effectiveTime"); 

Calendar  c2  =  getDateTimeSlots((lnstance)o2,  "effectiveDate",  "effectiveTime"); 
if  (  cl  ==  null ) 

return  c2  ==  null  ?  0  :  -1; 
else  if  (  c2  ==  null ) 
return  1 ; 

if  ( c1.before(c2) ) 

return -1; 

else  if  (  cl  .after(c2) ) 

return  1 ; 
else 

return  0; 

} 

}; 

I** 

*  Returns  the  task  currently  associated  with  an  organisation. 

*  <p>Currently,  just  returns  the  most  recently  created  task.  Does  not  check  if  the  task  applies  to  the  current  time. 

*  @return  The  task  currently  associated  with  an  organisation,  or  null  if  no  task  is  associated. 

**  i 

public  synchronized  Instance  currentTask(lnstance  org)  { 

Collection  orgActionTaskAssocList  =  org.getOwnSlotValues(_kb.getSlot("has-its-role-specified-through-OrganisationActionAssociation")); 
if  (  orgActionTaskAssocList  ==  null  ||  orgActionTaskAssocList. size()  ==  0  ) 
return  null; 

List  I  =  new  LinkedList(orgActionTaskAssocList); 

Collections. sort(l,  dtComparator); 
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Instance  currentOAA  =  (lnstance)l.get(l.size()-1); 

return  (lnstance)currentOAA.getOwnSlotValue(_kb.getSlot("org_act_assoc-is-associated-with-Action")); 

} 

I** 

*  Returns  the  task  currently  associated  with  an  organisation  or,  if  the  organisation  has  no  task,  the  task  associated  with  its  superiors. 

*  <p>Currently,  just  returns  the  last  task;  does  not  check  if  the  task  applies  to  the  current  time. 

*  @return  The  task  currently  associated  with  an  organisation,  or  null  if  no  task  is  associated. 

**  i 

public  synchronized  Instance  currentTasklnOrgHierarchy(lnstance  org)  { 

Set  orgsExamined  =  new  HashSet();  //  Just  in  case  the  org-org  assocs  have  a  circularity, 
for  (;;)  { 

List  orgActionTaskAssocList  = 

new  LinkedList(org.getOwnSlotValues(_kb.getSlot("has-its-role-specified-through-OrganisationActionAssociation"))); 
if  (  orgActionTaskAssocList  !=  null  &&  orgActionTaskAssocList.size()  >  0  )  { 

List  I  =  new  LinkedList(orgActionTaskAssocList); 

Collections. sort(l,  dtComparator); 

Instance  currentOAA  =  (Instance)! .get(l.size()-1 ); 

return  (lnstance)currentOAA.getOwnSlotValue(_kb.getSlot("org-action-task-assoc-is-associated-with-Action")); 

} 

Instance  commandingOrganisation  =  commandingOrganisation(org); 
if  (  commandingOrganisation  ==  null  ||  orgsExamined. contains(commandingOrganisation) ) 
return  null; 

orgsExamined.  add(commandingOrganisation); 
org  =  commandingOrganisation; 

} 

} 

I** 

*  Returns  the  organisation  that  commands  an  organisation  --  i.e. ,  is  the  subject  of  a  CMDCTL  association  where  the  specified  organisation  is 

*  an  object. 

*  <p>Currently  admits  of  no  more  than  one  commanding  organisation. 

*  @param  org  The  organisation  whose  commanding  organisation  is  to  be  determined. 

*  @return  The  commanding  organisation,  or  <code>null</code>  if  there  is  none. 

**  i 

public  synchronized  Instance  commandingOrganisation(lnstance  org)  { 

Collection  OlAs  =  org.getOwnSlotValues(_kb.getSlot("is-the-object-of-ObjectltemAssociation")); 
if  (  OlAs  ==  null  ||  OIAs.size()  ==  0  ) 
return  null; 
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Slot  subjectObjltemSIot  =  _kb.getSlot("subject-is-associated-with-Objectltem"); 
for  ( Iterator  oialter  =  OIAs.iterator();  oialter.hasNext();  )  { 

Instance  oia  =  (lnstance)oialter.next(); 

String  categoryCode  =  getCodeSlot(oia,  "categoryCode"); 
if  (  categoryCode  ==  null  ||  !  categoryCode. equalsfCMDCTL") ) 
continue; 

Instance  subjectObjltem  =  (Instance)oia.getOwnSlotValue(subjectObjltemSlot); 
if  (  subjectObjltem. instanceOf(_orgCls) ) 
return  subjectObjltem; 

} 

return  null; 

} 

I** 

*  Determines  whether  an  {@linkplain  ida.sd.ontology.lnstance}  of  one  <code>Organisation</code>  commands  another,  directly  or  indirectly. 

*  The  semantics  of  commanding  are  as  specified  by  the  {@link  #commandingOrganisation}  method. 

*  @param  orgl  An  organisation. 

*  @param  org2  An  organisation. 

*  @return  True  if  <code>org1</code>  commands  <code>org2</code>,  false  if  not. 

**  j 

public  synchronized  boolean  commands(lnstance  orgl,  Instance  org2)  { 

Instance  commandingOrg; 

commandingOrg  =  commandingOrganisation(org2); 
while  (  commandingOrg  !=  null )  { 

if  ( getObjectltemName(commandingOrg).equals(getObjectltemName(org1)) ) 
return  true; 

commandingOrg  =  commandingOrganisation(commandingOrg); 

} 

return  false; 

} 

/**  Supports  the  {@link  #supplyAdequacy}  method.  */ 
private  Map_supplyAdequacyMap  =  new  HashMap(); 

jit* 

*  Determines  if  an  organisation's  supplies  are  adequate.  Very  simple-minded.  Should  be  connected  to  the  organisation's 

*  ability  to  achieve  some  objective. 

**  j 

public  synchronized  double  supplyAdequacy(lnstance  org)  { 

II  The  current  implementation  works  as  follows:  Each  organisation  for  which  this  method  is  invoked  gets  a  randomly  assigned  value. 

II  The  distribution  is  weighted  such  that  the  probability  of  adequacy  is  3/4. 
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String  orgName  =  getObjectltemName(org); 
if  ( !  _supplyAdequacyMap.containsKey(orgName) )  { 
double  r  =  java. lang. Math. random(); 

_supplyAdequacyMap.put(orgName,  new  Double(r  <=  0.25  ?  r*0.75  :  r*0.25  +  0.75)); 

} 

return  ((Double)_supplyAdequacyMap.get(orgName)).doubleValue(); 

} 

///////////////////////////////////////////////////////////////////////////^^ 

II  The  following  methods  encapsulate  how  the  GH5  ontology  stores  values  in  slots. 

// 

II  We  provide  two  forms  of  each  method.  One  uses  a  slot  name.  The  other  uses  an  actual  Slot. 

Illlllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllll 

I** 

*  Returns  the  value  of  the  named  code-valued  {@link  Slot}  of  an  {@link  Instance}. 

*  @param  inst  An  instance  in  this  knowledge  base. 

*  @param  slotName  The  name  of  an  own  slot  of  <code>inst</code>. 

*  @return  The  value  of  the  named  {@link  Slot}  of  an  {@link  Instance}. 

**  j 

public  String  getCodeSlot(lnstance  inst,  String  slotName)  { 
return  getCodeSlot(inst,  _kb.getSlot(slotName)); 

} 

I** 

*  Returns  the  value  of  a  code-valued  {@link  Slot}  of  an  {@link  Instance}. 

*  @param  inst  An  instance  in  this  knowledge  base. 

*  @param  slotName  An  own  slot  of  <code>inst</code>. 

*  @return  The  value  of  <code>slot</code>. 

**  j 

public  String  getCodeSlot(lnstance  inst,  Slot  slot)  { 

Instance  codeTypedlnst  =  (Instance)inst.getOwnSlotValue(slot); 
if  (  codeTypedlnst  ==  null ) 
return  null; 

Instance  tiv  =  (lnstance)codeTypedlnst.getOwnSlotValue(_tivSlot); 
if  ( tiv  ==  null  ) 

throw  new  Error("Null  tiv  for "  +  inst.getDirectType().getName()  +  +  slot.getName()  +  ",  cti="  +  codeTypedlnst. getName()); 

return  (String)((lnstance)codeTypedlnst.getOwnSlotValue(_tivSlot)).getOwnSlotValue(_eelSlot); 

} 

j** 
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*  Sets  the  value  of  the  named  code-valued  {@link  ida.sd. ontology. Slot}  of  an  {@link  ida.sd.ontology. Instance}. 

*  @param  inst  An  instance  in  this  knowledge  base. 

*  @param  slotName  The  name  of  an  own  slot  of  <code>inst</code>. 

*  @param  code  The  code  to  which  the  named  slot  will  be  set. 

*  @throws  InvalidCodeException  If  <code>code</code>  is  not  a  valid  code  for  <code>slot</code>. 

**  j 

public  void  setCodeSlot(lnstance  inst,  String  slotName,  String  code) 
throws  InvalidCodeException  { 
setCodeSlot(inst,  _kb.getSlot(slotName),  code); 

} 

I** 

*  Sets  the  value  of  a  code-valued  {@link  ida.sd. ontology. Slot}  of  an  {@link  ida.sd.ontology. Instance}. 

*  @param  inst  An  instance  in  this  knowledge  base. 

*  @param  slotName  An  own  slot  of  <code>inst</code>. 

*  @param  code  The  code  to  which  the  slot  will  be  set.  If  <code>null</code>,  the  slot's  value  becomes  <code>null</code>. 

*  @throws  InvalidCodeException  If  <code>code</code>  is  not  a  valid  code  for  <code>slot</code>. 

**  j 

public  void  setCodeSlot(lnstance  inst,  Slot  slot,  String  code) 
throws  InvalidCodeException  { 
if  (  code  ==  null )  { 

inst.setOwnSlotValue(slot,  null); 

return; 

} 

CIs  enumCIs  =  allowedCls(inst,  slot); 

for  ( Iterator  eilter  =  enumCIs. getlnstances().iterator();  eilter.hasNext();  )  { 

Instance  enumlnst  =  (lnstance)eilter.next(); 

Instance  tiv  =  (lnstance)enumlnst.getOwnSlotValue(_tivSlot); 
if  ( tiv.getOwnSlotValue(_eelSlot).equals(code) )  { 
inst.setOwnSlotValue(slot,  enumlnst); 
return; 

} 

} 

throw  new  lnvalidCodeException(inst.getDirectType(),  slot,  code); 

} 

j ** 

*  Returns  the  value  of  the  named  floating-point  {@link  ida.sd. ontology.Slot}  of  an  {@link  ida.sd.ontology. Instance}. 

*  @param  inst  An  instance  in  this  knowledge  base. 
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*  @param  slotName  The  name  of  an  own  slot  of  <code>inst</code>. 

*  @return  The  value  of  the  named  {@link  ida.sd. ontology. Slot}  of  an  {@link  ida.sd.ontology.lnstance}. 

**  j 

public  Double  getFloatSlot(lnstance  inst,  String  slotName)  { 
return  getFloatSlot(inst,  _kb.getSlot(slotName)); 

} 

I** 

*  Returns  the  value  of  a  floating-point  {@link  ida.sd. ontology. Slot}  of  an  {@link  ida.sd.ontology.lnstance}. 

*  @param  inst  An  instance  in  this  knowledge  base. 

*  @param  slotName  An  own  slot  of  <code>inst</code>. 

*  @return  The  value  of  <code>slot</code>. 

**  j 

public  Double  getFloatSlot(lnstance  inst,  Slot  slot)  { 

Instance  floatTypedlnst  =  (Instance)inst.getOwnSlotValue(slot); 
if  ( floatTypedlnst  ==  null ) 
return  null; 

Instance  tiv  =  (lnstance)(floatTypedlnst.getOwnSlotValue(_tivSlot)); 

if  ( tiv.getDirectType().hasSuperclass(_numericExpressionCls) )  { 

Number  n  =  _numericExpression.evaluate(tiv); 

return  n  instanceof  Double  ?  (Double)n  :  new  Double(n.doubleValue()); 

} 

else  { 

throw  new  TIVError(inst,  slot,  _numericExpressionCls,  tiv.getDirectType()); 

} 

} 

j ** 

*  Sets  the  value  of  the  named  floating-point  {@link  ida.sd.ontology.Slot}  of  an  {@link  ida.sd.ontology.lnstance}. 

*  @param  inst  An  instance  in  this  knowledge  base. 

*  @param  slotName  The  name  of  an  own  slot  of  <code>inst</code>. 

*  @param  value  The  value  to  which  the  named  slot  will  be  set. 

**  j 

public  void  setFloatSlot(lnstance  inst,  String  slotName,  Number  value)  { 
setFloatSlot(inst,  _kb.getSlot(slotName),  value); 

} 

j ** 

*  Sets  the  value  of  a  floating-point  {@link  ida.sd.ontology.Slot}  of  an  {@link  ida.sd.ontology.lnstance}. 

*  @param  inst  An  instance  in  this  knowledge  base. 
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*  @param  slotName  An  own  slot  of  <code>inst</code>. 

*  @param  value  The  value  to  which  the  slot  will  be  set.  If  <code>null</code>,  the  slot's  value  becomes  <code>null</code>. 

**  j 

public  void  setFloatSlot(lnstance  inst,  Slot  slot,  Number  value)  { 
if  (  value  ==  null )  { 

inst.setOwnSlotValue(slot,  null); 

return; 

} 

setNumericSlot(inst,  slot,  _numericExpression.createLiteral(value.floatValue())); 

} 

jit* 

*  Returns  the  value  of  the  named  integer-valued  {@link  ida.sd.ontology.Slot}  of  an  {@link  ida.sd.ontology. Instance}. 

*  @param  inst  An  instance  in  this  knowledge  base. 

*  @param  slotName  The  name  of  an  own  slot  of  <code>inst</code>. 

*  @return  The  value  of  the  named  {@link  ida.sd.ontology.Slot}  of  an  {@link  ida.sd.ontology.lnstance}. 

**  j 

public  Integer  getlntSlot(lnstance  inst,  String  slotName)  { 
return  getlntSlot(inst,  _kb.getSlot(slotName)); 

} 

j ** 

*  Returns  the  value  of  an  integer-valued  {@link  ida.sd.ontology.Slot}  of  an  {@link  ida.sd.ontology.lnstance}. 

*  @param  inst  An  instance  in  this  knowledge  base. 

*  @param  slot  An  own  slot  of  <code>inst</code>. 

*  @return  The  value  of  <code>slot</code>. 

**  j 

public  Integer  getlntSlot(lnstance  inst,  Slot  slot)  { 

Instance  intTypedlnst  =  (Instance)inst.getOwnSlotValue(slot); 
if  ( intTypedlnst  ==  null ) 
return  null; 

Instance  tiv  =  (lnstance)(intTypedlnst.getOwnSlotValue(_tivSlot)); 
if  ( tiv.getDirectType().hasSuperclass(_numericExpressionCls) )  { 

Number  n  =  _numericExpression.evaluate(tiv); 

return  n  instanceof  Integer  ?  (Integer)n  :  new  lnteger(n.intValue()); 

} 

else  { 

throw  new  TIVError(inst,  slot,  _numericExpressionCls,  tiv.getDirectType()); 

} 
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} 

I** 

*  Sets  the  named  integer-valued  {@link  ida.sd. ontology. Slot}  of  an  {@link  ida.sd. ontology. Instance}  to  a  specified  value. 

*  @param  inst  An  instance  in  this  knowledge  base. 

*  @param  slotName  The  name  of  an  own  slot  of  <code>inst</code>. 

*  @param  value  The  value  to  which  the  named  slot  will  be  set. 

**  i 

public  void  setlntSlot(lnstance  inst,  String  slotName,  Integer  value)  { 
setlntSlot(inst,  _kb.getSlot(slotName),  value); 

} 

jit* 

*  Sets  an  integer-valued  {@link  ida.sd. ontology. Slot}  of  an  {@link  ida.sd. ontology.lnstance}  to  a  given  value. 

*  @param  inst  An  instance  in  this  knowledge  base. 

*  @param  slot  An  own  slot  of  <code>inst</code>. 

*  @param  value  The  value  to  which  the  slot  will  be  set.  If  <code>null</code>,  the  slot's  value  becomes  <code>null</code>. 

**  j 

public  void  setlntSlot(lnstance  inst,  Slot  slot,  Integer  value)  { 
if  (  value  ==  null )  { 

inst.setOwnSlotValue(slot,  null); 

return; 

} 

setNumericSlot(inst,  slot,  _numericExpression.createLiteral(value)); 

} 

I** 

*  Sets  the  value  of  a  {@link  ida.sd. ontology. Slot}  that  takes  a  numeric  value. 

*  @param  inst  An  {@link  ida.sd. ontology. Instance} 

*  @param  slot  An  own  slot  of  <code>inst</code>  that  takes  a  numeric  value. 

*  @param  slotValue  An  instance  of  the  <code>Numeric-Literal</code>  {@link  ida.sd. ontology.CIs}. 

**  j 

private  void  setNumericSlot(lnstance  inst,  Slot  slot,  Instance  slotValue)  { 

CIs  tivCIs  =  allowedTIVCIs(inst,  slot); 

if  (  !  tivCIs. equals(_numericExpressionCls) ) 

throw  new  TIVError(inst,  slot,  _numericExpressionCls,  tivCIs); 

Instance  slotlnst  =  allowedCls(inst,  slot).createDirectlnstance(); 
slotlnst.setOwnSlotValue(_tivSlot,  slotValue); 

inst.setOwnSlotValue(slot,  slotlnst); 
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} 

I** 

*  Returns  a  {@link  java. util. Calendar}  for  the  date  and  time  denoted  by 

*  named  {@linkplain  ida.sd. ontology. Slot  slots}  of  an  {@link  ida.sd. ontology. Instance}. 

*  @param  inst  An  instance  in  this  knowledge  base. 

*  @param  dateSlotName  The  name  of  an  own  slot  of  <code>inst</code>  that  denotes  a  date. 

*  @param  timeSlotName  The  name  of  an  own  slot  of  <code>inst</code>  that  denotes  a  time. 

*  @return  A  {@link  java. util. Calendar}  for  the  date  and  time  denoted  by  the  named  slots. 

**  j 

public  Calendar  getDateTimeSlots(lnstance  inst,  String  dateSlotName,  String  timeSlotName)  { 
return  getDateTimeSlots(inst,  _kb.getSlot(dateSlotName),  _kb.getSlot(timeSlotName)); 

} 

I** 

*  Returns  a  {@link  java. util. Calendar}  for  the  date  and  time  denoted  by  {@linkplain  ida.sd.ontology.Slot  slots}  of  an 

*  {@link  ida.sd. ontology.lnstance}. 

*  @param  inst  An  instance  in  this  knowledge  base. 

*  @param  dateSlot  A  own  slot  of  <code>inst</code>  that  denotes  a  date. 

*  @param  timeSlot  An  own  slot  of  <code>inst</code>  that  denotes  a  time. 

*  @return  A  {@link  java. util. Calendar}  for  the  date  and  time  denoted  by  the  slots. 

**  j 

public  Calendar  getDateTimeSlots(lnstance  inst,  Slot  dateSlot,  Slot  timeSlot)  { 

Instance  dateTIV  =  (Instance)inst.getOwnSlotValue(dateSlot); 

Instance  timeTIV  =  (Instance)inst.getOwnSlotValue(timeSlot); 
if  (  dateTIV  ==  null  ||  timeTIV  ==  null ) 
return  null; 

Integer  time  =  (lnteger)_numericExpression.evaluate((lnstance)timeTIV.getOwnSlotValue(_tivSlot)); 
return  DateTime.getCalendar((String)dateTIV.getOwnSlotValue(_tivSlot),  time.toString()); 

} 

j ** 

*  Given  the  names  of  two  {@linkplain  ida.sd.ontology.Slot  slots}  of  an  {@link  ida.sd. ontology. Instance}  that  model  a  date  and  a  time, 

*  sets  the  slots  to  the  date  and  time  of  a  specified  moment. 

*  @param  inst  An  instance  in  this  knowledge  base. 

*  @param  dateSlotName  The  name  of  an  own  slot  of  <code>inst</code>  that  denotes  a  date. 

*  @param  timeSlotName  The  name  of  an  own  slot  of  <code>inst</code>  that  denotes  a  time. 

*  @param  moment  A  moment  in  time. 

**  j 

public  void  setDateTimeSlots(lnstance  inst,  String  dateSlotName,  String  timeSlotName,  Calendar  moment)  { 
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setDateTimeSlots(inst,  _kb.getSlot(dateSlotName),  _kb.getSlot(timeSlotName),  moment); 

} 

I** 

*  Given  two  {@linkplain  ida.sd. ontology. Slot  slots}  of  an  {@link  ida. sd. ontology. Instancejthat  model  a  date  and  a  time,  sets  the  slots  to  the 

*  date  and  time  of  a  specified  moment. 

*  @param  inst  An  instance  in  this  knowledge  base. 

*  @param  dateSlot  An  own  slot  of  <code>inst</code>  that  denotes  a  date. 

*  @param  timeSlot  An  own  slot  of  <code>inst</code>  that  denotes  a  time. 

*  @param  moment  A  moment  in  time. 

**  j 

public  void  setDateTimeSlots(lnstance  inst,  Slot  dateSlot,  Slot  timeSlot,  Calendar  moment)  { 
setDateSlot(inst,  dateSlot,  moment); 
setTimeSlot(inst,  timeSlot,  moment); 

} 

I** 

*  Returns  a  {@link  java. util. Calendar}  for  the  date  denoted  by  the  named  {@linkplain  ida.sd. ontology. Slot  slot}  of  an 

*  {@link  ida.sd. ontology.lnstance}. 

*  @param  inst  An  instance  in  this  knowledge  base. 

*  @param  dateSlotName  The  name  of  an  own  slot  of  <code>inst</code>  that  denotes  a  date. 

*  @return  A  {@link  java. util. Calendar}  for  the  date  denoted  by  <code>dateSlotName</code>. 

**  j 

public  Calendar  getDateSlot(lnstance  inst,  String  dateSlotName)  { 
return  getDateSlot(inst,  _kb.getSlot(dateSlotName)); 

} 

j ** 

*  Returns  a  {@link  java. util. Calendar}  for  the  date  denoted  by  an  own  {@linkplain  ida.sd. ontology. Slot  slot}  of  an 

*  {@link  ida.sd. ontology.lnstance}. 

*  @param  inst  An  instance  in  this  knowledge  base. 

*  @param  dateSlot  An  own  slot  of  <code>inst</code>  that  denotes  a  date. 

*  @return  A  {@link  java. util. Calendar}  for  the  date  denoted  by  <code>dateSlot</code>. 

**  j 

public  Calendar  getDateSlot(lnstance  inst,  Slot  dateSlot)  { 

Instance  dateTIV  =  (Instance)inst.getOwnSlotValue(dateSlot); 
if  (  dateTIV  ==  null ) 
return  null; 

return  DateTime.getDateCalendar((String)dateTIV.getOwnSlotValue(_tivSlot)); 
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I** 

*  Given  the  name  of  a  {@linkplain  ida.sd.ontology.Slot  slot}  of  an  {@link  ida.sd. ontology. Instance}  that  models  a  date, 

*  sets  that  slot  to  the  date  of  a  specified  moment. 

*  @param  inst  An  instance  in  this  knowledge  base. 

*  @param  dateSlotName  The  name  of  an  own  slot  of  <code>inst</code>  that  denotes  a  date. 

*  @param  date  A  moment  in  time.  Time  fields  are  ignored;  only  date  information  is  used. 

**  j 

public  void  setDateSlot(lnstance  inst,  String  dateSlotName,  Calendar  date)  { 
setDateSlot(inst,  _kb.getSlot(dateSlotName),  date); 

} 

jit* 

*  Given  a  {@linkplain  ida.sd.ontology.Slot  slot}  of  an  {@link  ida.sd. ontology. Instance}  that  models  a  date, 

*  sets  that  slot  to  the  date  of  a  specified  moment. 

*  @param  inst  An  instance  in  this  knowledge  base. 

*  @param  dateSlot  An  own  slot  of  <code>inst</code>  that  denotes  a  date. 

*  @param  date  A  moment  in  time.  Time  fields  are  ignored;  only  date  information  is  used. 

**  j 

public  void  setDateSlot(lnstance  inst,  Slot  dateSlot,  Calendar  date)  { 
if  (  date  ==  null )  { 

inst.setOwnSlotValue(dateSlot,  null); 

return; 

} 

II  The  following  assumes  a  date  is  represented  as  a  string. 

Instance  dateTIV  =  allowedCls(inst,  dateSlot). createDirectlnstance(); 
dateTIV.setOwnSlotValue(_tivSlot,  DateTime.dateToString(date)); 
inst.setOwnSlotValue(dateSlot,  dateTIV); 

} 

j ** 

*  Given  the  name  of  a  {@linkplain  ida.sd.ontology.Slot  slot}  of  an  {@link  ida.sd. ontology. Instance}  that  models  a  time, 

*  returns  that  slot's  value  as  the  number  of  seconds  since  midnight. 

*  @param  inst  An  instance  in  this  knowledge  base. 

*  @param  timeSlotName  The  name  of  an  own  slot  of  <code>inst</code>  that  denotes  a  time. 

*  @return  The  value  of  <code>timeSlotName</code>  as  the  number  of  seconds  since  midnight. 

**  j 

public  Integer  getTimeSlot(lnstance  inst,  String  timeSlotName)  { 
return  getTimeSlot(inst,  _kb.getSlot(timeSlotName)); 


D-24 


I** 

*  Given  a  {@linkplain  ida.sd. ontology. Slot  slot}  of  an  {@link  ida.sd. ontology. Instance}  that  models  a  time, 

*  returns  that  slot's  value  as  the  number  of  seconds  since  midnight. 

*  @param  inst  An  instance  in  this  knowledge  base. 

*  @param  timeSlot  An  own  slot  of  <code>inst</code>  that  denotes  a  time. 

*  @return  The  value  of  <code>timeSlot</code>  as  the  number  of  seconds  since  midnight. 

**  j 

public  Integer  getTimeSlot(lnstance  inst,  Slot  timeSlot)  { 

Instance  timeTIV  =  (Instance)inst.getOwnSlotValue(timeSlot); 
if  ( timeTIV  ==  null ) 
return  null; 

return  (lnteger)_numericExpression.evaluate((lnstance)timeTIV.getOwnSlotValue(_tivSlot)); 

} 

I** 

*  Given  the  name  of  a  {@linkplain  ida.sd. ontology.Slot  slot}  of  an  {@link  ida.sd.ontology. Instance}  that  models  a  time, 

*  sets  that  slot's  value  to  a  specified  time. 

*  @param  inst  An  instance  in  this  knowledge  base. 

*  @param  timeSlotName  The  name  of  an  own  slot  of  <code>inst</code>  that  denotes  a  time. 

*  @param  time  The  time  to  which  <code>timeSlotName</code>'s  value  will  be  set.  Only  the  time  information  is  used; 

*  date  information  is  ignored. 

**  j 

public  void  setTimeSlot(lnstance  inst,  String  timeSlotName,  Calendar  time)  { 
setTimeSlot(inst,  _kb.getSlot(timeSlotName),  time); 

} 

j ** 

*  Given  a  {@linkplain  ida.sd. ontology. Slot  slot}  of  an  {@link  ida.sd.ontology. Instance}  that  models  a  time, 

*  sets  that  slot's  value  to  a  specified  time. 

*  @param  inst  An  instance  in  this  knowledge  base. 

*  @param  timeSlot  An  own  slot  of  <code>inst</code>  that  denotes  a  time. 

*  @param  time  The  time  to  which  <code>timeSlot</code>'s  value  will  be  set.  Only  the  time  information  is  used;  date  information  is  ignored. 

**  j 

public  void  setTimeSlot(lnstance  inst,  Slot  timeSlot,  Calendar  time)  { 
if  ( time  ==  null )  { 

inst.setOwnSlotValue(timeSlot,  null); 

return; 

} 

//  A  time  is  represented  as  a  integral  numeric  expression 
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//  denoting  seconds  past  midnight. 

Instance  timeTIV  =  allowedCls(inst,  timeSlot).createDirectlnstance(); 

timeTIV.setOwnSlotValue(_tivSlot,  _numericExpression.createLiteral(DateTime.timeTolnt(time))); 
inst.setOwnSlotValue(timeSlot,  timeTIV); 

} 

I** 

*  Returns  the  value  of  the  named  string-valued  {@link  ida.sd. ontology. Slot}  of  an  {@link  ida.sd.ontology. Instance}. 

*  @param  inst  An  instance  in  this  knowledge  base. 

*  @param  slotName  The  name  of  an  own  slot  of  <code>inst</code>. 

*  @return  The  value  of  the  named  {@link  ida.sd. ontology. Slot}  of  an  {@link  ida.sd. ontology.lnstance}. 

**  j 

public  String  getStringSlot(lnstance  inst,  String  slotName)  { 
return  getStringSlot(inst,  _kb.getSlot(slotName)); 

} 

I** 

*  Returns  the  value  of  a  string-valued  {@link  ida.sd. ontology. Slot}  of  an  {@link  ida.sd.ontology. Instance}. 

*  @param  inst  An  instance  in  this  knowledge  base. 

*  @param  slotName  An  own  slot  of  <code>inst</code>. 

*  @return  The  value  of  <code>slot</code>. 

**  j 

public  String  getStringSlot(lnstance  inst,  Slot  slot)  { 

Instance  stringTypedlnst  =  (Instance)inst.getOwnSlotValue(slot); 

return  stringTypedlnst  !=  null  ?  (String)stringTypedlnst.getOwnSlotValue(_tivSlot) :  null; 

} 

j ** 

*  Sets  the  named  string-valued  {@link  ida.sd. ontology. Slot}  of  an  {@link  ida.sd.ontology. Instance}  to  a  specified  value. 

*  @param  inst  An  instance  in  this  knowledge  base. 

*  @param  slotName  The  name  of  an  own  slot  of  <code>inst</code>. 

*  @param  value  The  value  to  which  the  named  slot  will  be  set. 

*  @throws  StringLengthException  If  <code>value</code>  is  longer  than  the  maximum  length  allowed  for  the  named  slot. 

**  j 

public  void  setStringSlot(lnstance  inst,  String  slotName,  String  value)  throws  StringLengthException  { 
setStringSlot(inst,  _kb.getSlot(slotName),  value); 

} 

j ** 

*  Sets  a  string-valued  {@link  ida.sd  .ontology. Slot}  of  an  {@link  ida.sd. ontology. Instance}  to  a  given  value. 

*  @param  inst  An  instance  in  this  knowledge  base. 
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*  @param  slot  An  own  slot  of  <code>inst</code>. 

*  @param  value  The  value  to  which  the  slot  will  be  set.  If  <code>null</code>,  the  slot's  value  becomes  <code>null</code>. 

*  @throws  StringLengthException  If  <code>value</code>  is  longer  than  the  maximum  length  allowed  for  <code>slot</code>. 

**  i 

public  void  setStringSlot(lnstance  inst,  Slot  slot,  String  value)  throws  StringLengthException  { 
if  (  value  ==  null )  { 

inst.setOwnSlotValue(slot,  null); 

return; 

} 

CIs  stringType  =  allowedCls(inst,  slot); 

Instance  vlnst  =  stringType. createDirectlnstance(); 

int  length  =  ((lnteger)stringType.getOwnSlotValue(_stringLengthSlot)).intValue(); 
if  (  value. Iength()  >  length  ) 

throw  new  StringLengthException(value,  length); 
if  (  stringType. hasSuperclass(_fixedLengthStringCls) )  { 

String  Buffer  vb  =  new  StringBuffer(length).append(value); 
for  ( int  i  =  value. Iength();  i  <  length;  i++  ) 
vb.append(' '); 

vlnst. setOwnSlotValue(_tivSlot,  vb.toString()); 

} 

else  { 

vlnst. setOwnSlotValue(_tivSlot,  value); 

} 

inst.setOwnSlotValue(slot,  vlnst); 

} 

private  CIs  allowedCls(lnstance  inst,  Slot  slot)  { 

Collection  allowedCIses  =  inst.getDirectType().getTemplateSlotAllowedClses(slot); 
if  (  allowedCIses. size()  !=  1  ) 

throw  new  AllowedClsesCollectionSizeError(inst,  slot,  allowedCIses); 
return  (Cls)allowedClses.iterator().next(); 

} 

private  CIs  allowedTIVCIs(lnstance  inst,  Slot  slot)  { 

CIs  allowedCIs  =  allowedCls(inst,  slot); 

Collection  allowedTIVCIses  =  allowedCIs. getTemplateSlotAllowedClses(_tivSlot); 
if  (  allowedTIVCIses. size()  !=  1  ) 

throw  new  AllowedClsesCollectionSizeError(allowedCls,  tivSIot,  allowedTIVCIses); 
return  (Cls)allowedTIVCIses.iterator().next(); 
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} 

I** 

*  Uses  system  properties  to  construct  a  <code>GH5KB</code>  instance,  and  returns  that  instance. 

*  These  properties  are  as  follows: 

*  <ul> 

*  <li>The  knowledge  base  to  open  is  the  value  of  {@link  ida.eh.Properties#ontologyURL}.</li> 

*  <li>lf  the  {@link  ida.eh.Properties#dataSource}  is  <code>"db"</code>,  the  knowledge  base  is  populated  from  a  database. 

*  See  {@link  ida.sd.osb.BindingPA}  for  details. </li> 

*  </ul> 

*  This  method  explicitly  binds  the  knowledge  base  to  a 

*  {@linkplain  ida.sd. ontology. impl. protege. ProtegeProject  Protege-2000  based  implementation}. 

*  @return  A  <code>GH5KB</code>  instance  created  from  the  value  of  the  <code>ontologyURL</code>  property, 

*  and  maybe  loaded  with  data  from  the  <code>dataSource</code>  property. 

*  @throws  OntologyLoadException  If  the  knowledge  base  cannot  be  created  for  any  reason. 

**  j 

public  static  GH5KB  loadFromProperties()  throws  OntologyLoadException  { 

II  Open  the  ontology. 

GH5KB  kb  =  openFromProperties(); 

II  Load  data  into  the  knowledge  base,  if  so  specified. 

String  dataSource  =  System.getProperty(ida. eh. Properties. dataSource); 
if  (  dataSource  !=  null )  { 

if  (  dataSource. equalsfdb") )  { 

try  { 

BindingPA.IoadDBUsingSystemProperties(kb); 

}  catch  (  BindingException  e  )  { 

throw  new  OntologyLoadException(e); 

} 

} 

else  { 

throw  new  OntologyLoadException("Unknown  external  data  source  V"  +  dataSource  + 

} 

} 

return  kb; 

} 

I** 

*  Creates  a  <code>GH5KB</code>  using  the  value  of  system  property  {@link  ida.eh.Properties#ontologyURL}  as  the  ontology.  This  method 

*  explicitly  binds  the  knowledge  base  to  a 
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*  {@linkplain  ida.sd.ontology.impl. protege. ProtegeProject  Prot&eacute;g&eacute;-2000  based  implementation}. 

*  @return  A  <code>GH5KB</code>  instance  created  from  the  value  of  the  <code>ontologyURL</code>  property. 

*  @throws  OntologyLoadException  If  the  <code>ontologyURL</code>  property  is  missing,  or  if  Prot&eacute;g&eacute;-2000  fails  to  load  the 

*  ontology  from  the  specified  URL. 

**  j 

public  static  GH5KB  openFromProperties()  throws  OntologyLoadException  { 

String  ontologyURL; 

if  ( (ontologyURL  =  System. getProperty(ida. eh. Properties. ontologyURL))  —  null ) 

throw  new  OntologyLoadException("Missing  property  V"  +  ida. eh. Properties. ontologyURL  +  "\"  (ontology  URL)"); 

try  { 

return  new  GH5KB(new  ProtegeProject(ontologyURL).getKnowledgeBase()); 

}  catch  (  ProtegeProject. ProjectException  e  )  { 
throw  new  OntologyLoadException(e); 

} 

} 

} 

3.  Class  DateTime 

GH-conformant  data  sets  have  their  own  set  of  rules  for  representing  dates  and  times.  Dates  are  usually  represented  as  8-character 
strings  of  the  form  YYYYMMDD.  Times  are  usually  represented  as  6-character  strings  of  decimal  digits  interpreted  as  seconds  since 
midnight. 

The  GH  ontology  uses  the  Generic  Hub’s  format  to  represent  dates.  For  an  instance  of  class  A.D.  Date,  the  value  type  of  own  slot  type- 
instance-value  is  a  string.  The  GH  ontology  represents  times  as  instances  of  the  Numeric-Expression  class. 

These  representations  were  chosen  mainly  for  convenience  in  loading  Generic  Hub  data  sets.  They  might  change  in  the  future,  so  it’s 
desirable  to  hide  them  from  other  classes.  This  is  the  purpose  of  class  DateTime.  It  provides  methods  that  convert  between  GH  ontol¬ 
ogy  representations  of  dates  and  times  and  Java  representations. 

package  ida.sd.gh5ontology; 

import  java. text. DecimalFormat; 
import  java. text. SimpleDateFormat; 

import  java. util. Calendar; 
import  java. util. GregorianCalendar; 

jit* 

*  The  <code>DateTime</code>  class  provides  procedural  abstractions  for  manipulating  dates  and  times  in  a  GH5  knowledge  base. 
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*  These  abstractions  convert  GH5-formatted  dates  and  times  to  Java  class  instances  and  vice  versa.  The  primary  secrets  of  this  class  are: 

*  <ol> 

*  <li>The  format  of  dates  and  times  in  a  GH5  knowledge  base  (but  <em>not</em>  their  representation  in  a  database;  that  secret  is 

*  more  general). </li> 

*  <li>The  algorithms  for  converting  between  GH5  formats  and  Java  formats. </li> 

*  </ol> 

**  j 

public  class  DateTime  { 

/**  Ensures  that  no  instances  of  this  class  are  constructed.  */ 

private  DateTime()  {} 

I** 

*  Converts  a  date/time  pair  expressed  in  GH5  format  into  a  {@link  Calendar}. 

*  <p>The  sample  data  set  we  have  includes  times  that  are  right-padded  with  blanks.  I  don't  know  whether  this  is  strictly  legal,  but 

*  we  allow  it  in  this  method. 

*  @param  date  An  8-character  string  of  the  form  <code>yyyymmdd</code>. 

*  @param  time  A  6-character  string  denoting  seconds  since  midnight. 

*  @return  A  {@link  Calendar}  expressing  the  given  date/time  pair. 

**  j 

public  static  Calendar  getCalendar(String  date,  String  time)  { 

int  year  =  lnteger.valueOf(date.substring(0,  4)).intValue(); 

int  month  =  lnteger.valueOf(date. substring^,  6)).intValue()  - 1 ; 

int  day  =  lnteger.valueOf(date. substring^,  8)).intValue(); 

int  timeSeconds  =  lnteger.valueOf(time.trim()).intValue(); 

int  hour  =  timeSeconds/3600; 

int  mins  =  (timeSeconds  -  hour*60)/60; 

int  secs  =  timeSeconds  -  hour*3600  -  mins*60; 

return  new  GregorianCalendar(year,  month,  day,  hour,  mins,  secs); 

} 

j ** 

*  Converts  a  date  expressed  in  GH5  format  into  a  {@link  java. util. Calendar}.  Time  information  is  not  set. 

*  @param  date  An  8-character  string  of  the  form  <code>yyyymmdd</code>. 

*  @return  A  {@link  java. util. Calendar}  expressing  the  given  date. 

**  j 

public  static  Calendar  getDateCalendar(String  date)  { 

int  year  =  lnteger.valueOf(date.substring(0,  4)).intValue(); 
int  month  =  lnteger.valueOf(date. substring^,  6)).intValue()  - 1; 
int  day  =  lnteger.valueOf(date. substring^,  8)).intValue(); 
return  new  GregorianCalendar(year,  month,  day); 
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} 

/**  Encapsulates  the  <code>CHAR(8)</code>  format  of  GH5  date  attributes.  7 

private  final  static  SimpleDateFormat  DATE_FORMAT  =  new  SimpleDateFormat("yyyyMMdd"); 

jit* 

*  Returns  the  date  information  associated  with  a  {@link  Calendar}  as  a  GH5-formatted  date. 

*  @param  calendar  A  calendar. 

*  @return  The  date  information  of  <code>calendar</code>  as  an  8-character  string  of  the  form  <code>yyyymmdd</code>. 

**  j 

public  static  String  dateToString(Calendar  calendar)  { 
return  DATE_FORMAT.format(calendar.getTimeQ); 

} 

jit* 

*  Returns  the  time  information  associated  with  a  {@link  Calendar}  as  seconds  since  midnight. 

*  @param  calendar  A  calendar. 

*  @return  The  time  information  of  <code>calendar</code>  as  seconds  since  midnight. 

**  j 

public  static  Integer  timeTolnt(Calendar  calendar)  { 
int  hours  =  calendar.get(Calendar.HOUR_OF_DAY); 
int  mins  =  calendar.get(Calendar.MINUTE); 
int  secs  =  calendar.get(Calendar.SECOND); 
return  new  lnteger(hours*3600  +  mins*60  +  secs); 

} 

/**  Encapsulates  the  <code>CHAR(6)</code>  format  of  GH5  time  attributes.  7 
private  final  static  DecimalFormat  TIME_FORMAT  =  new  DecimalFormat("000000"); 

j ** 

*  Returns  the  time  information  associated  with  a  {@link  Calendar}  as  a  GH5-formatted  time. 

*  @param  calendar  A  calendar. 

*  @return  The  time  information  of  <code>calendar</code>  as  a  6-character  string  denoting  seconds  since  midnight. 

**  j 

public  static  String  timeToString(Calendar  calendar)  { 

return  TIME_FORMAT.format(timeTolnt(calendar).longValue()); 

} 

} 
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4.  Class  NumericExpression 

GH  ontology  slots  that  model  numeric  quantities  have  an  instance  of  class  Numeric-Expression  as  the  value  type  of  their  type-instance- 
value  own  slot.  This  representation  aids  inferencing  by  allowing  functional  expression.  Specifying  a  bearing  angle  as  45°  is  fine,  but 
stating  it  as  the  arcsine  of  some  expression  that  equals  0.707106  may  help  agents  understand  how  the  bearing  angle  was  derived.  The 
GH  ontology  allows  both  forms. 

Most  of  the  time,  an  agent  will  simply  want  the  numeric  value  of  a  slot  rather  than  its  structure.  The  NumericExpression  class  encapsu¬ 
lates  how  an  instance  of  the  Numeric-Expression  class  in  the  GH  ontology  can  be  translated  into  a  numeric  value.  It  does  so  through  the 
method  evaluate(),  which  when  applied  to  an  instance  of  Numeric-Expression  yields  a  Java  Number. 

package  ida.sd.gh5ontology; 
import  java. util. Iterator; 
import  ida.sd.ontology.*; 

jit* 

*  The  <code>NumericExpression</code>  class  encapsulates  the  <code>Numeric-Expression</code>  {@link  CIs}  in  the  GH  ontology.  It  hides 

*  decisions  on  the  representation  of  that  class.  The  primary  secrets  of  this  class  are  the  representation  (slots  and  their  facets)  of  the 

*  <code>Numeric-Expression</code>  class,  and  the  algorithms  for  manipulating  instances  of  <code>NumericExpression</code>. 

**  i 

public  class  NumericExpression  { 

llllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllll 
//  The  following  fields  are  used  to  cache  classes  and  frames  that  are  commonly  used  when  evaluating  a  NumericExpresison. 
Illlllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllllll 
private  final  CIs  JntegerLiteralCIs; 
private  final  CIs  _realLiteralCls; 

private  final  Slot  valueSlot; 
private  final  Slot  baseSlot; 
private  final  Slot  descrSlot; 

private  final  CIs  productCIs; 
private  final  CIs  sumCIs; 
private  final  CIs  differenceCIs; 
private  final  CIs  divisionCIs; 

private  final  Slot  operandsSlot; 

private  final  static  Integer  TEN  =  new  Integer(IO); 

I** 


D-32 


*  Constructs  a  <code>NumericExpression</code>  instance. 

*  @param  gh5KB  A  GH5  knowledge  base. 

**  i 

public  NumericExpression(KnowledgeBase  gh5KB)  { 

_integerl_iteralCls  =  gh5KB.getCls("lnteger-Literal"); 

_ realLiteralCIs  =  gh5KB.getCls("Real-Literal"); 

_valueSlot  =  gh5KB.getSlot("value"); 

_baseSlot  =  gh5KB.getSlot("base"); 

_descrSlot  =  gh5KB.getSlot("description"); 

_productCls  =  gh5KB.getCls("Product"); 

_sumCls  =  gh5KB.getCls("Sum"); 

_differenceCls  =  gh5KB.getCls("Difference"); 

_divisionCls  =  gh5KB.getCls("Division"); 

_operandsSlot  =  gh5KB.getSlot("operands"); 

} 

I** 

*  Creates  an  {@link  Instance}  of  an  <code>lnteger-Literal</code>  from  an  {@link  Integer}.  The  base  is  10,  and  the  description  is  the  string 

*  image  of  the  parameter. 

*  @param  i  The  value  for  the  literal. 

**  j 

public  Instance  createLiteral(lnteger  i)  { 

Instance  inst  =  JntegerLiteralCls.createDirectlnstance(); 
inst.setOwnSlotValue(_valueSlot,  i); 
inst.setOwnSlotValue(_baseSlot,  _TEN); 
inst.setOwnSlotValue(_descrSlot,  i.toString()); 
return  inst; 

} 

jit* 

*  Creates  an  {@link  Instance}  of  an  <code>lnteger-Literal</code>  from  an  <code>int</code>. 

*  The  base  is  10,  and  the  description  is  the  string  image  of  the  parameter. 

*  @param  i  The  value  for  the  literal. 

**  j 

public  Instance  createLiteral(int  i)  { 
return  createLiteral(new  Integer(i)); 

} 

j ** 
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*  Creates  an  {@link  Instance}  of  a  <code>Real-Literal</code>  from  a  {@link  Float}. 

*  The  base  is  10,  and  the  description  is  the  string  image  of  the  parameter. 

*  @param  f  The  value  for  the  literal. 

**  j 

public  Instance  createLiteral(Float  f)  { 

Instance  inst  =  _realLiteralCls.createDirectlnstance(); 
inst.setOwnSlotValue(_valueSlot,  f); 
inst.setOwnSlotValue(_baseSlot,  _TEN); 
inst.setOwnSlotValue(_descrSlot,  f.toString()); 
return  inst; 

} 

I** 

*  Creates  an  {@link  Instance}  of  a  <code>Real-Literal</code>  from  a  <code>float</code>. 

*  The  base  is  10,  and  the  description  is  the  string  image  of  the  parameter. 

*  @param  f  The  value  for  the  literal. 

**  j 

public  Instance  createLiteral(float  f)  { 
return  createLiteral(new  Float(f)); 

} 

j ** 

*  Returns  the  {@link  java. lang. Number}  that  results  from  evaluating  an  {@link  ida.sd.ontology.lnstance}  of  {@link  ida.sd.ontology.CIs} 

*  <code>NumericExpression</code>.  The  type  of  the  result  will  be  either  {@link  java. lang. Integer}  or  {@link  java. lang. Double}. 

*  @param  i  The  instance  to  evaluate. 

*  @return  The  <code>Number</code>  that  results  from  evaluating  the  instance. 

**  j 

public  Number  evaluate(lnstance  i)  { 

if  ( i.getDirectType().equals(_integerLiteralCls) ) 
return  (lnteger)i.getOwnSlotValue(_valueSlot); 
else  if  ( i.getDirectType().equals(_realLiteralCls) ) 

return  new  Double(((Float)i.getOwnSlotValue(_valueSlot)).doubleValue()); 
else  if  ( i.getDirectType().equals(_productCls) )  { 

Iterator  olter  =  i.getOwnSlotValues(_operandsSlot).iterator(); 
if  ( !  olter.hasNext() ) 
return  null; 

Number  product  =  evaluate((lnstance)olter.next()); 
while  (  olter.hasNext() )  { 

Number  nextTerm  =  evaluate((lnstance)olter.next()); 

if  (  nextTerm  instanceof  Double  ||  product  instanceof  Double  ) 
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product  =  new  Double(product.doubleValue()  *  nextTerm.doubleValue()); 

else 

product  =  new  lnteger(product.intValue()  *  nextTerm.intValue()); 

} 

return  product; 

} 

else  if  ( i.getDirectType().equals(_sumCls) )  { 

Iterator  olter  =  i.getOwnSlotValues(_operandsSlot).iterator(); 
if  ( !  olter.hasNext() ) 
return  null; 

Number  sum  =  evaluate((lnstance)olter.next()); 
while  (  olter.hasNext() )  { 

Number  nextTerm  =  evaluate((lnstance)olter.next()); 

if  (  nextTerm  instanceof  Double  ||  sum  instanceof  Double  ) 

sum  =  new  Double(sum.doubleValue()  +  nextTerm.doubleValue()); 

else 

sum  =  new  lnteger(sum.intValue()  +  nextTerm. intValue()); 

} 

return  sum; 

} 

else  if  ( i.getDirectType().equals(_differenceCls) )  { 

Iterator  olter  =  i.getOwnSlotValues(_operandsSlot).iterator(); 
if  ( !  olter.hasNext() ) 
return  null; 

Number  difference  =  evaluate((lnstance)olter.next()); 
while  (  olter.hasNext() )  { 

Number  nextTerm  =  evaluate((lnstance)olter.next()); 

if  (  nextTerm  instanceof  Double  ||  difference  instanceof  Double  ) 

difference  =  new  Double(difference.doubleValue()  -  nextTerm.doubleValue()); 

else 

difference  =  new  lnteger(difference.intValue()  -  nextTerm. intValue()); 

} 

return  difference; 

} 

else  if  ( i.getDirectType().equals(_divisionCls) )  { 

Iterator  olter  =  i.getOwnSlotValues(_operandsSlot).iterator(); 
if  ( !  olter.hasNext() ) 
return  null; 

Number  quotient  =  evaluate((lnstance)olter.next()); 
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while  (  olter.hasNext() )  { 

Number  nextTerm  =  evaluate((lnstance)olter.next()); 

if  (  nextTerm  instanceof  Double  ||  quotient  instanceof  Double  ) 

quotient  =  new  Double(quotient.doubleValue()  /  nextTerm. doubleValue()); 

else 

quotient  =  new  lnteger(quotient.intValue()  /  nextTerm. intValue()); 

} 

return  quotient; 

} 

else  { 

throw  new  Error("Not  yet  handling  "  +  i.getDirectType().getName()  +  "  in  numeric  expressions"); 

} 

} 

} 

5.  Class  ReportingData 

Reporting  data  is  a  crucial  concept  in  the  Generic  Hub,  and  therefore  in  the  GH  ontology  as  well.  In  particular,  it  implements  time- 
sequenced  observations.  Many  agents  in  the  IDA  prototype  simulation  need  to  know  about  the  most  recent  observation  of  some  battle¬ 
field  object  property. 

The  ReportingData  class  contains  a  collection  of  static  methods  that  support  orderings  of  sets  of  instances  based  on  the  associated  val¬ 
ues  of  REPORTING-DATA.  Note  that,  aside  from  getEffectiveTime(),  the  methods  work  with  instances  of  classes  that  have  associated  REPORT¬ 
ING-DATA  (e.g.,  ObjectltemLocation)  rather  than  with  instances  of  ReportingData.  This  is  generally  what  a  user  needs. 

package  ida.sd.gh5ontology; 

import  java. util. Calendar; 
import  java. util. Collection; 
import  java. util. Collections; 
import  java. util. Iterator; 
import  java. util. List; 

import  ida.sd.ontology.*; 

I** 

*  The  <code>ReportingData</code>  class  contains  procedural  abstractions  for  dealing  with  instances  of  the  GH5  <code>ReportingData</code> 

*  class.  Each  instance  of  <code>ReportingData</code>  has  slots  that  specify  a  moment  in  time.  The  methods  in  this  class  understand  those 

*  slots  and  how  they  can  be  used  to  order  instances.  The  primary  secrets  of  this  class  are  the  slots  that  order  reporting  data,  and  the  algorithms 

*  for  ordering  a  collection  of  instances. 
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**  i 

public  class  ReportingData  { 

/**  Ensures  that  no  instances  of  this  class  are  created.  7 
private  ReportingData()  {} 

jit* 

*  Given  a  homogeneous  {@link  Collection}  of  {@link  Instancejs  that  are  associated  with  <code>ReportingData</code>,  returns  the  most 

*  recent  instance  of  the  collection  as  determined  by  reporting  date/time.  An  instance  of  class  {@link  RDComparator}  determines  which  is  most 

*  recent. 

*  @param  gh5KB  A  GH5  knowledge  base. 

*  @param  instances  A  homogeneous  (i.e. ,  all  of  the  same  {@link  CIs})  collection  of  {@linkplain  Instance  instances}. 

*  @param  relatedReportingDataSlot  A  template  slot  of  the  {@link  CIs}  of  all  members  of  <code>instances</code>. 

*  @return  The  member  of  <code>instances</code>  whose  <code>ReportingData</code>  instance,  as  obtained  from 

*  <code>relatedReportingDataSlot</code>,  is  more  recent  than  all  other  members.  If  <code>instances</code>  has  no  members, 

*  returns  <code>null</code>. 

**  j 

public  static  Instance  getMostRecent(GH5KB  gh5KB,  Collection  instances,  Slot  relatedReportingDataSlot)  { 
if  ( instances. size()  ==  0  ) 
return  null; 

java. util. Comparator  c  =  new  RDComparator(gh5KB,  relatedReportingDataSlot); 

Iterator  instlter  =  instances. iterator(); 

Instance  mostRecentlnst  =  (lnstance)instlter.next(); 

Instance  mostRecentRD  =  (Instance)mostRecentlnst.getOwnSlotValue(relatedReportingDataSlot); 

while  ( instlter.hasNext() )  { 

Instance  candidatelnst  =  (lnstance)instlter.next(); 

Instance  candidateRD  =  (Instance)candidatelnst.getOwnSlotValue(relatedReportingDataSlot); 
if  (  candidateRD  ==  null ) 
continue; 

else  if  (  mostRecentRD  ==  null  ||  c.compare(candidateRD,  mostRecentRD)  >  0  )  { 
mostRecentlnst  =  candidatelnst; 
mostRecentRD  =  candidateRD; 

} 

} 

return  mostRecentlnst; 

} 

jit* 

*  Sorts  a  list  of  {@linkplain  Instance  instances}  according  to  the  reporting  date/times  of  their  associated  <code>ReportingData</code>. 
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*  @param  gh5kb  A  GH5  knowledge  base. 

*  @param  instances  A  homogeneous  list  of  instances.  On  return,  will  be  ordered  according  to  related  reporting  data. 

*  @param  relatedReportingDataSlot  A  template  slot  of  the  {@link  CIs}  of  all  members  of  <code>instances</code>. 

**  j 

public  static  void  sortByReportingTime(GH5KB  gh5kb,  List  instances,  Slot  relatedReportingDataSlot)  { 

Collections. sort(instances,  new  RDComparator(gh5kb,  relatedReportingDataSlot)); 

} 

I** 

*  Sorts  a  list  of  {@linkplain  Instance  instances}  according  to  the  effective  date/times  of  their  associated  <code>ReportingData</code>. 

*  @param  gh5kb  A  GH5  knowledge  base. 

*  @param  instances  A  homogeneous  list  of  instances.  On  return,  will  be  ordered  according  to  related  reporting  data. 

*  @param  relatedReportingDataSlot  A  template  slot  of  the  {@link  CIs}  of  all  members  of  <code>instances</code>. 

**  j 

public  static  void  sortByEffectiveTime(GH5KB  gh5kb,  List  instances,  Slot  relatedReportingDataSlot)  { 

Collections. sort(instances,  new  RDEComparator(gh5kb,  relatedReportingDataSlot)); 

} 

I** 

*  Returns  the  effective  time  of  an  instance  of  <code>ReportingData</code>. 

*  @param  gh5kb  A  GH5  knowledge  base. 

*  @param  rd  An  {@link  Instance}  of  <code>ReportingData</code>. 

*  @return  The  effective  time  of  an  instance  of  <code>ReportingData</code>,  or  <code>null</code>  if  the  effective  time  cannot  be  computed. 

**  j 

public  static  Calendar  getEffectiveTime(GH5KB  gh5kb,  Instance  rd)  { 
if  ( rd.instanceOf(gh5kb.getCls("ReportingDataAbsoluteTiming")) )  { 
return  gh5kb.getDateTimeSlots(rd,  "effectiveDate",  "effectiveTime"); 

} 

else  if  ( rd.instanceOf(gh5kb.getCls("ReportingDataRelativeTiming")) )  { 

//  ReportingDataRelativeTiming  is  w.r.t.  an  ActionTask.  We  use  the  ActionTask's  planned  start  date  and  startPrecisionCode. 

//  It's  possible  we  need  to  consider  startGualifierCode,  but  I'm  not  sure  how. 

Integer  duration  =  gh5kb.getlntSlot(rd,  gh5kb.getSlot("offsetDuration")); 
if  (  duration  ==  null ) 
return  null; 

Instance  associatedActionTask  =  (lnstance)rd.getOwnSlotValue(gh5kb.getSlot("rdrt-uses-as-timing-ref-ActionTask")); 

Calendar  actionTaskPlannedStart  =  gh5kb.getDateTimeSlots(associatedActionTask,  "plannedStartDate",  "plannedStartTime"); 
if  (  actionTaskPlannedStart  ==  null ) 
return  null; 

String  precisionCode  =  gh5kb.getCodeSlot(associatedActionTask,  "startPrecisionCode"); 
if  (  precisionCode  ==  null  ||  precisionCode. equals("NKN") ) 
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return  null; 

int  d  =  duration.  intValue(); 

if  (  precisionCode.equals("DAY") ) 

actionTaskPlannedStart.add(Calendar.DATE,  d); 
else  if  (  precisionCode.equals("HR") ) 

actionTaskPlannedStart.add(Calendar.HOUR_OF_DAY,  d); 
else  if  (  precisionCode.equals("MINUTE") ) 

actionTaskPlannedStart.add(Calendar.MINUTE,  d); 
else  if  (  precisionCode.equals("MON") ) 

actionTaskPlannedStart.add(Calendar. MONTH,  d); 
else  if  (  precisionCode.equals("SECOND") ) 

actionTaskPlannedStart.add(Calendar.SECOND,  d); 
else  if  (  precisionCode.equals("WEK") ) 

actionTaskPlannedStart.add(Calendar.WEEK_OF_MONTH,  d); 
else  if  (  precisionCode.equalsfYEA") ) 

actionTaskPlannedStart.add(Calendar.YEAR,  d); 
else 

throw  new  IHegalArgumentException(  "Instance  "  +  associatedActionTask.getName()  + 

Unknown  startPrecisionCode  \""  +  precisionCode  + 

return  actionTaskPlannedStart; 

} 

else  { 

return  null; 

} 

} 

I** 

*  Compares  two  <code>ReportingData</code>  instances  according  to  their  reporting  date/time  slots.  The  return  value  follows  Java's 

*  {@linkplain  java. util. Comparator#compare  comparator  protocol}. 

*  <p>Reporting  date  is  a  required  slot;  reporting  time  is  not.  Lack  of  reporting  time  interpreted  to  be  prior  to  presence  thereof.  If  both 

*  <code>i1</code>  and  <code>i2</code>  lack  reporting  time,  they  are  considered  equal. 

*  @param  kb  A  {@link  GH5KB}  in  which  <code>i1</code>  and  <code>i2</code>  exist. 

*  @param  il  An  {@link  Instance}  of  <code>ReportingData</code>. 

*  @param  i2  An  {@link  Instance}  of  <code>ReportingData</code>. 

*  @return  A  negative  integer  if  the  moment  specified  by  <code>i1</code>  is  before  the  moment  specified  by  <code>i2</code>;  0  if  they 

*  specify  the  same  moment;  a  positive  integer  if  the  moment  specified  by  <code>i1</code>  is  after  the  moment  specified  by 

*  <code>i2</code>. 

*  @throws  lllegalArgumentException  If  <code>i1</code>  and  <code>i2</code>  are  not  both  instances  of  the 
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*  <code>ReportingData</code>  class. 

**  i 

public  static  int  compareByReportingDateTime(GH5KB  kb,  Instance  i  1 ,  Instance  i2)  { 

CIs  reportingDataCIs  =  kb.getCIsfReportingData"); 
if  ( !  H.instanceOf(reportingDataCls) ) 

throw  new  HlegalArgumentException(i1.getName()  +  "  is  not  an  instance  of  ReportingData"); 
if  ( !  i2.instanceOf(reportingDataCls) ) 

throw  new  HlegalArgumentException(i2.getName()  +  "  is  not  an  instance  of  ReportingData"); 

Slot  reportingDateSlot  =  kb.getSlotfreportingDate"); 

Slot  reportingTimeSlot  =  kb.getSlot("reportingTime"); 

Calendar  reportingDTI  =  kb.getDateTimeSlots(i1,  reportingDateSlot,  reportingTimeSlot); 

Calendar  reportingDT2  =  kb.getDateTimeSlots(i2,  reportingDateSlot,  reportingTimeSlot); 
if  ( reportingDTI. after(reportingDT2) ) 

return  1; 

else  if  ( reportingDTI. equals(reportingDT2) ) 

return  0; 
else 

return  -1; 

} 

I** 

*  Compares  two  <code>ReportingData</code>  instances  according  to  their  effective  date/time  slots.  The  return  value  follows  Java's 

*  {@linkplain  java. util. Comparator#compare  comparator  protocol}. 

*  <p>Effective  date/time  has  a  precision.  It  is  used  to  form  a  range.  Overlap  of  ranges  indicates  equality. 

*  <p>Effective  date  is  a  required  slot;  effective  time  is  not.  Lack  of  effective  time  interpreted  to  be  prior  to  presence  thereof.  If  both 

*  <code>i1</code>  and  <code>i2</code>  lack  reporting  time,  they  are  considered  equal. 

*  @param  kb  A  {@link  GH5KB}  in  which  <code>i1</code>  and  <code>i2</code>  exist. 

*  @param  il  An  {@link  Instance}  of  <code>ReportingData</code>. 

*  @param  i2  An  {@link  Instance}  of  <code>ReportingData</code>. 

*  @return  A  negative  integer  if  the  moment  specified  by  <code>i1</code>  is  before  the  moment  specified  by  <code>i2</code>;  0  if  they 

*  specify  the  same  moment;  a  positive  integer  if  the  moment  specified  by  <code>i1</code>  is  after  the  moment  specified  by 

*  <code>i2</code>. 

*  @throws  HlegalArgumentException  If  <code>i1</code>  and  <code>i2</code>  are  not  both  instances  of  the 

*  <code>ReportingData</code>  class. 

**  i 

public  static  int  compareByEffectiveDateTime(GH5KB  kb,  Instance  il,  Instance  i2)  { 

CIs  reportingDataCIs  =  kb.getCIsfReportingData"); 
if  ( !  il.instanceOf(reportingDataCls) ) 

throw  new  HlegalArgumentException(i1.getName()  +  "  is  not  an  instance  of  ReportingData"); 
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if  ( !  i2.instanceOf(reportingDataCls) ) 

throw  new  HlegalArgumentException(i2.getName()  +  "  is  not  an  instance  of  ReportingData"); 

Slot  precisionCodeSlot  =  kb.getSlotfprecisionCode"); 

EffectiveDT  effectiveDTI  =  minMax(kb,  il,  precisionCodeSlot); 

EffectiveDT  effectiveDT2  =  minMax(kb,  i2,  precisionCodeSlot); 

if  (  effectiveDTI. max.before(effectiveDT2. min) ) 

return  -1 ; 

else  if  (  effectiveDT  1  .min.after(effectiveDT2.max) ) 

return  1; 
else 

return  0; 

} 

private  static  EffectiveDT  minMax(GH5KB  kb,  Instance  i,  Slot  precisionCodeSlot)  { 

Calendar  effectiveDT  =  getEffectiveTime(kb,  i); 

EffectiveDT  dt  =  new  EffectiveDT(); 
dt.min  =  (Calendar)effectiveDT.clone(); 
dt.max  =  (Calendar)effectiveDT.cloneQ; 

if  ( !  i.instanceOf(kb.getCls("ReportingDataAbsoluteTiming")) ) 

return  dt;  II  More  likely,  we  should  be  using  start-precision-code. 

String  precision  =  kb.getCodeSlot(i,  precisionCodeSlot); 
if  (  precision. equals("DAY") )  { 

dt.min.add(Calendar.HOUR_OF_DAY,  -12); 
dt.max.add(Calendar.HOUR_OF_DAY,  12); 

} 

else  if  (  precision. equals("HR") )  { 
dt.min. add(Calendar.MINUTE,  -30); 
dt.max.add(Calendar.MINUTE,  30); 

} 

else  if  (  precision. equals("MINUTE") )  { 
dt.min.add(Calendar.SECOND,  -30); 
dt.max. add(Calendar.SECOND,  30); 

} 

else  if  (  precision. equals("MON") )  { 

int  days  =  effectiveDT. getActualMaximum(Calendar.DAY_OF_MONTH)/2; 
dt.min.add(Calendar.DAY_OF_MONTH,  -days); 
dt.max.add(Calendar.DAY_OF_MONTH,  days); 
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} 

else  if  (  precision. equals("NKN") )  { 

//  No  effect. 

} 

else  if  (  precision. equals("SECOND") )  { 

dt. min. add(Calendar. MILLISECOND,  -500); 
dt.max.add(Calendar.MILLISECOND,  500); 

} 

else  if  (  precision. equals("WEK") )  { 

//  84  ==  half  the  hours  in  a  week. 
dt.min.add(Calendar.HOUR_OF_DAY,  -84); 
dt.max.add(Calendar.HOUR_OF_DAY,  84); 

} 

else  if  (  precision. equalsfYEA") )  { 

int  days  =  effectiveDT.getActualMaximum(Calendar.DAY_OF_YEAR)/2; 
dt.min.add(Calendar.DAY_OF_YEAR,  -days); 
dt.max.add(Calendar.DAY_OF_YEAR,  days); 

} 

else  { 

throw  new  NlegalArgumentException("lnstance  "  +  i.getName()  +  "  has  invalid  precision  code  V"  +  precision  +  "\""); 

} 

return  dt; 

} 

private  static  class  EffectiveDT  { 

Calendar  min; 

Calendar  max; 

} 

} 

6.  Class  RDComparator 

There  are  two  ways  to  compare  two  instances  of  REPORTING-DATA.  Instances  may  be  compared  based  on  reporting  date/time  (the  mo¬ 
ment  when  an  observation  is  made)  or  effective  date/time  (the  moment  when  the  observation  becomes,  became,  or  will  become  effec¬ 
tive).  Class  RDComparator  supports  comparison  based  on  reporting  date/time. 

The  class  supports  the  standard  Java  paradigm  for  comparison  by  implementing  interface  java.util. Comparator.  This  requires  an  imple¬ 
mentation  of  method  compareQ,  which,  given  two  objects,  returns  an  integer  value  denoting  whether  one  object  is  equal  to,  less  than, 
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or  greater  than  the  second.  The  IDA  prototype  implementation  of  compare()  makes  some  arguable  choices  based  on  whether  one  or 
both  instances  have  missing  slot  values.  A  production  system  will  require  a  thorough  examination  of  these  choices. 

Note  that  the  comparison  is  of  instances  that  have  associated  instances  of  REPORTING-DATA,  not  on  instances  of  ReportingData. 
package  ida.sd.gh5ontology; 
import  ida.sd.ontology.*; 

I** 

*  The  <code>RDComparator</code>  class  supports  comparing  GH5  class  {@link  Instance  instances}  that  have  an  associated 

*  <code>ReportingData</code>  item  based  on  reporting  date/time.  Examples  of  such  classes  include  <code>ObjectltemLocation</code> 

*  and  <code>Holding</code>. 

*  <p>Two  instances  are  compared  based  on  the  values  of  their  <code>reportingDate</code>  and  <code>reportingTime</code>  slots. 

*  <p>The  primary  secret  of  this  class  is  the  algorithm  for  comparison. 

**  j 

public  class  RDComparator 

implements  java. util. Comparator  { 

private  final  GH5KB  _gh5KB; 

private  final  Slot_relatedReportingDataSlot; 
private  final  Slot  reportingDateSlot; 
private  final  Slot_reportingTimeSlot; 
private  final  Slot  tivSIot; 

jit* 

*  Constructs  an  <code>RDComparator</code>  from  a  {@link  Slot}. 

*  @param  gh5KB  A  GH5  knowledge  base. 

*  @param  relatedReportingDataSlot  A  {@link  Slot}  whose  value  type  is  {@link  Instance},  whose  allowed  class  is 

<code>ReportingData</code>,  and  whose  cardinality  is  1.  It  should  be  an  inverse  slot  of  a  slot  in  <code>ReportingData</code>. 

**  j 

public  RDComparator(GH5KB  gh5KB,  Slot  relatedReportingDataSlot)  { 

_gh5KB  =  gh5KB; 

RelatedReportingDataSlot  =  relatedReportingDataSlot; 

_reportingDateSlot  =  gh5KB.getSlot("reportingDate"); 

_reportingTimeSlot  =  gh5KB.getSlot("reportingTime"); 
tivSIot  =  gh5KB.getSlot("type-instance-value"); 

} 

j ** 

*  Constructs  an  <code>RDComparator</code>  from  a  {@link  Slot}  name. 

*  @param  gh5KB  A  GH5  knowledge  base. 
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*  @param  relatedReportingDataSlotName  The  name  of  a  {@link  Slot}  whose  value  type  is  {@link  Instance},  whose  allowed  class  is 

*  <code>ReportingData</code>,  and  whose  cardinality  is  1 .  It  should  be  an  inverse  slot  of  a  slot  in  <code>ReportingData</code>. 

**  i 

public  RDComparator(GH5KB  gh5KB,  String  relatedReportingDataSlotName)  { 
this(gh5KB,  gh5KB.getSlot(relatedReportingDataSlotName)); 

} 

I** 

*  Implements  the  {@link  java. util. Comparator#compare}  method  to  compare  two  instances  in  a  GH5  ontology.  It  is  assumed  that: 

*  <ol> 

*  <li>Both  <code>o1</code>  and  <code>o2</code>  are  instances  of  {@link  Instance}. </li> 

*  <li><code>((lnstance)o1  ).getDirectType().equals((lnstance)o2).getDirectType()</code>  is  true.</li> 

*  <li>The  slot  (or  slot  name)  given  to  the  constructor  of  this  instance  is  a  slot  of  class  <code>((lnstance)o1  ).getDirectType()</code>.</li> 

*  </ol> 

*  @param  ol  An  object  that  is  an  instance  of  {@link  Instance}. 

*  @param  o2  An  object  that  is  an  instance  of  {@link  Instance}. 

*  @return  Let  <i>r</i><sub>1  </sub>  be  the  <code>ReportingData</code>  associated  with  <code>o1</code>,  and  let  <i>r</i><sub>2</sub> 

*  be  the  <code>ReportingData</code>  associated  with  <code>o2</code>.  This  method  returns: 

*  <ul> 

*  <li>A  negative  integer  if  the  <code>reportingDate</code>  and  <code>reportingTime</code>  slots  of  <i>r</i><sub>1  </sub>  denote  a 

*  moment  before  the  <code>reportingDate</code>  and  <code>reportingTime</code>  slots  of  <i>r</i><sub>2</sub>.</li> 

*  <li>0  if  these  slots  denote  the  same  moment. </li> 

*  <li>A  positive  integer  if  the  <code>reportingDate</code>  and  <code>reportingTime</code>  slots  of  <i>r</i><sub>  1  </sub>  denote  a 

*  moment  after  the  <code>reportingDate</code>  and  <code>reportingTime</code>  slots  of  <i>r</i><sub>2</sub>.</li> 

*  </ul> 

*  Lack  of  reporting  data,  or  lack  of  reporting  date  or  reporting  time,  is  interpreted  to  be  prior  to  presence  thereof.  If  both 

*  <code>o1</code>  and  <code>o2</code>  lack  reporting  data,  date,  or  time,  they  are  considered  equal. 

**/ 

public  int  compare(Object  ol ,  Object  o2)  { 

Instance  il  =  (Instance)ol; 

Instance  i2  =  (lnstance)o2; 

Instance  rdlnstl  =  (lnstance)i1.getOwnSlotValue(_relatedReportingDataSlot); 

Instance  rdlnst2  =  (lnstance)i2.getOwnSlotValue(_relatedReportingDataSlot); 

if  ( rdlnstl  ==  null ) 

return  rdlnst2  ==  null  ?  0  :  -1; 
else  if  ( rdlnst2  ==  null ) 

return  1; 

return  ReportingData.compareByReportingDateTime(_gh5KB,  rdlnstl,  rdlnst2); 
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} 

} 

7.  Class  RDEComparator 

There  are  two  ways  to  compare  two  instances  of  REPORTING-DATA.  Instances  may  be  compared  based  on  reporting  date/time  (the  mo¬ 
ment  when  an  observation  is  made)  or  effective  date/time  (the  moment  when  the  observation  becomes,  became,  or  will  become  effec¬ 
tive).  Class  RDEComparator  supports  comparison  based  on  effective  date/time. 

The  class  supports  the  standard  Java  paradigm  for  comparison  by  implementing  interface  java.util. Comparator.  This  requires  an  imple¬ 
mentation  of  method  compare(),  which,  given  two  objects,  returns  an  integer  value  denoting  whether  one  object  is  equal  to,  less  than, 
or  greater  than  the  second.  The  implementation  of  compare()  makes  some  arguable  choices  based  on  whether  one  or  both  instances 
have  missing  slot  values.  A  production  system  would  want  to  examine  these  choices. 

Note  that  the  comparison  is  of  instances  that  have  associated  instances  of  REPORTING-DATA,  not  on  instances  of  ReportingData. 

package  ida.sd.gh5ontology; 

import  java. util. Calendar; 
import  java. util. Comparator; 

import  ida.sd. ontology.*; 

I** 

*  The  <code>RDEComparator</code>  class  supports  comparing  GH5  class  {@link  Instance  instances}  that  have  an  associated 

*  <code>ReportingData</code>  item  based  on  effective  date/time.  Examples  of  such  classes  include  <code>ObjectltemLocation</code> 

*  and  <code>Holding</code>. 

*  <p>The  primary  secret  of  this  class  is  the  algorithm  for  comparison. 

**/ 

public  class  RDEComparator 
implements  Comparator  { 

private  final  GH5KB  _gh5kb; 

private  final  Slot_relatedReportingDataSlot; 

jit* 

*  Constructs  an  <code>RDEComparator</code>  from  a  {@link  Slot}. 

*  @param  gh5KB  A  GH5  knowledge  base. 

*  @param  relatedReportingDataSlot  A  {@link  Slot}  whose  value  type  is  {@link  Instance},  whose  allowed  class  is 

*  <code>ReportingData</code>,  and  whose  cardinality  is  1 .  It  should  be  an  inverse  slot  of  a  slot  in  <code>ReportingData</code>. 

**  i 
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public  RDEComparator(GH5KB  gh5KB,  Slot  relatedReportingDataSlot)  { 

_gh5kb = gh5KB; 

_relatedReportingDataSlot  =  relatedReportingDataSlot; 

} 

I** 

*  Constructs  an  <code>RDEComparator</code>  from  a  {@link  Slot}  name. 

*  @param  gh5KB  A  GH5  knowledge  base. 

*  @param  relatedReportingDataSlotName  The  name  of  a  {@link  Slot}  whose  value  type  is  {@link  Instance},  whose  allowed  class  is 

*  <code>ReportingData</code>,  and  whose  cardinality  is  1 .  It  should  be  an  inverse  slot  of  a  slot  in  <code>ReportingData</code>. 

**  j 

public  RDEComparator(GH5KB  gh5KB,  String  relatedReportingDataSlotName)  { 
this(gh5KB,  gh5KB.getSlot(relatedReportingDataSlotName)); 

} 

I** 

*  Implements  the  {@link  Comparator#compare}  method  to  compare  two  instances  in  a  GH5  ontology.  It  is  assumed  that: 

*  <ol> 

*  <li>Both  <code>o1</code>  and  <code>o2</code>  are  instances  of  {@link  Instance}. </li> 

*  <li><code>((lnstance)o1  ).getDirectType().equals((lnstance)o2).getDirectType()</code>  is  true.</li> 

*  <li>The  slot  (or  slot  name)  given  to  the  constructor  of  this  instance  is  a  slot  of  class  <code>((lnstance)o1  ).getDirectType()</code>.</li> 

*  </ol> 

*  @param  ol  An  object  that  is  an  instance  of  {@link  Instance}. 

*  @param  o2  An  object  that  is  an  instance  of  {@link  Instance}. 

*  @return  Let  <i>r</i><sub>1</sub>  be  the  <code>ReportingData</code>  associated  with  <code>o1</code>,  and  let  <i>r</i><sub>2</sub> 

*  be  the  <code>ReportingData</code>  associated  with  <code>o2</code>.  This  method  returns: 

*  <ul> 

*  <li>A  negative  integer  if  the  <code>effectiveDate</code>  and  <code>effectiveTime</code>  slots  of  <i>r</i><sub>  1  </sub>  denote  a 

*  moment  before  the  <code>effectiveDate</code>  and  <code>effectiveTime</code>  slots  of  <i>r</i><sub>2</sub> 

*  (if  <i>r</i><sub>1</sub>  is  relative  timing  data,  its  absolute  effective  time  is  computed). </li> 

*  <li>0  if  these  slots  denote  the  same  moment. </li> 

*  <li>A  positive  integer  if  the  <code>effectiveDate</code>  and  <code>effectiveTime</code>  slots  of  <i>r</i><sub>1</sub>  denote  a 

*  moment  after  the  <code>effectiveDate</code>  and  <code>effectiveTime</code>  slots  of  <i>r</i><sub>2</sub>.</li> 

*  </ul> 

*  Lack  of  reporting  data,  or  lack  of  effective  date  or  effective  time,  is  interpreted  to  be  prior  to  presence  thereof.  If  both 

*  <code>o1</code>  and  <code>o2</code>  lack  reporting  data,  date,  or  time,  they  are  considered  equal. 

**  j 

public  int  compare(Object  ol ,  Object  o2)  { 

Instance  il  =  (Instance)ol; 

Instance  i2  =  (lnstance)o2; 
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Instance  rdlnstl  =  (Instance)il  .getOwnSlotValue(_relatedReportingDataSlot); 

Instance  rdlnst2  =  (lnstance)i2.getOwnSlotValue(_relatedReportingDataSlot); 

if  ( rdlnstl  ==  null ) 

return  rdlnst2  ==  null  ?  0  :  -1; 
else  if  ( rdlnst2  ==  null ) 

return  1; 

return  ReportingData.compareByEffectiveDateTime(_gh5kb,  rdlnstl,  rdlnst2); 

} 

} 

8.  Exceptions 

Methods  in  the  package  gh5ontology  encounter  a  common  set  of  erroneous  situations.  The  following  subsections  characterize  these 
situations  as  exceptions. 

8.1.  Class  InvalidCodeException 

An  InvalidCodeException  signals  an  attempt  to  use  the  GH  ontology  improperly.  For  example,  the  caller  is  trying  to  set  the  value  of  an 
own  slot  whose  value  type  is  a  coded  domain,  but  has  used  a  code  that  is  not  valid  for  that  domain, 
package  ida.sd.gh5ontology; 
import  ida.sd.ontology.*; 

I** 

*  The  <code>lnvalidCodeException</code>  class  signals  an  attempt  to  set  a  code-valued  slot  to  a  code  that  is  not  in  the  legal  set  of  values. 

**  i 

public  class  InvalidCodeException 
extends  Exception  { 

jit* 

*  Constructs  an  <code>lnvalidCodeException</code>  with  a  standard  message. 

*  @param  els  A  <code>Cls</code>  for  which  an  attempt  was  made  to  set  the  code. 

*  @param  slot  The  template  slot  of  <code>cls</code>  whose  code  was  attempted  to  be  set. 

*  @param  code  The  value  to  which  <code>slot</code>  was  requested  to  be  set. 

**  j 

public  lnvalidCodeException(Cls  els,  Slot  slot,  String  code)  { 

super(cls.getName()  +  +  slot.getName()  +  Invalid  code  V"  +  code  + 

} 

} 
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8.2.  Class  NoLocationException 

Several  methods  in  the  GH5KB  class  expect  a  battlefield  object  to  have  a  location.  The  NoLocationException 
no  location  has  ever  been  associated  with  a  given  battlefield  object;  that  is,  the  value  of  the  object’s  own 
through-ObjectltemLocation  is  null. 

package  ida.sd.gh5ontology; 

jit* 

*  The  <code>NoLocationException</code>  class  signals  a  situation  where  a  battlefield  object  was  expected  to  have 

**  i 

public  class  NoLocationException 
extends  Exception  { 

jit* 

*  Constructs  a  <code>NoLocationException</code>. 

*  @param  objltemName  The  name  of  a  battlefield  object. 

**  j 

public  NoLocationException(String  objltemName)  { 
super(objltemName); 

} 

} 

8.3.  Class  Ontology LoadException 

The  GH5KB  class  contains  some  methods  that  assist  in  loading  a  GH  knowledge  base.  The  OntologyLoadException  class  is  used  to  signal 
that  loading  failed  for  some  reason. 

package  ida.sd.gh5ontology; 

public  class  OntologyLoadException  extends  Exception  { 
public  OntologyLoadException(String  message)  { 
super(message); 

} 

public  OntologyLoadException(Throwable  th)  { 

super(th); 

} 


class  is  used  to  signal  that 
slot  is-geometrically-defined- 


a  location,  but  didn't. 
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8.4.  Class  SpeedlndeterminateException 

Several  methods  in  the  GH5KB  class  expect  a  battlefield  object  to  have  a  speed.  The  SpeedlndeterminateException  class  is  used  to  signal 
that  no  speed  can  be  determined.  It  should  be  noted  that  speed  can  be  determined  in  two  ways.  One  is  the  value  of  the  speedRate  own 
slot  of  the  most  recent  ObjectltemLocation  instance  (as  determined  by  reporting  data)Objectl  tern  Location  instance  associated  with  a  battle¬ 
field  object.  This  value  is  preferred;  but  if  absent,  speed  can  also  be  computed  from  the  last  two  locations  of  the  object, 
package  ida.sd.gh5ontology; 

I** 

*  The  <code>SpeedlndeterminateException</code>  class  signals  an  attempt  to  compute  the  speed  of  a  battlefield  object  in  a  context  where  the 

*  speed  is  indeterminate. 

**  i 

public  class  SpeedlndeterminateException 
extends  Exception  { 

I** 

*  Constructs  a  <code>SpeedlndeterminateException</code>. 

*  @param  objltemName  The  name  of  a  battlefield  object. 

**  j 

public  SpeedlndeterminateException(String  objltemName)  { 
super(objltemName); 

} 

} 

8.5.  Class  StringLengthException 

String-valued  columns  in  the  Generic  Hub  have  a  predefined  maximum  length.  The  GH  ontology  adheres  to  that  length;  it  is  enforced 
by  classes  in  the  gh5ontology  package.  A  StringLengthException  is  thrown  if  the  maximum  length  is  violated, 
package  ida.sd.gh5ontology; 

I** 

*  The  <code>StringLengthException</code>  class  signals  an  attempt  to  set  a  string-typed  slot  to  a  length  longer  than  permitted. 

**  j 

public  class  StringLengthException 
extends  Exception  { 

j ** 

*  Constructs  a  <code>StringLengthException</code>  with  a  standard  message. 

*  @param  s  The  string  that  is  too  long. 

*  @param  maxLength  The  maximum  number  of  characters  permitted. 
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**  i 

public  StringLengthException(String  s,  int  maxLength)  { 

super("\""  +  s  +  "\"  is  longer  than  "  +  maxLength  +  "  characters"); 

} 

} 

9.  Errors 

The  gh5ontology  package  contains  several  classes  that  extend  Error. These  classes  denote  situations  that  were  deemed  valuable  in  detect¬ 
ing  implementation  errors  during  debugging.  The  class  OntologyDefinitionError,  for  example  (which  three  classes  in  this  section  extend) 
indicates  a  problem  in  the  ontology  that  must  be  corrected. 

An  important  purpose  of  these  classes  is  to  standardize  error  reporting.  The  constructors  often  have  combinations  of  parameters  that 
are  unusual  for  subclasses  of  Throwable. 

On  reflection,  it  would  be  better  to  make  these  classes  extend  Exception.  A  production  system  might  encounter  them  through,  say,  a 
configuration  error  in  which  an  old  version  of  the  GH  ontology  is  used. 

9.1.  Class  AllowedClsesCollectionSizeError 

Some  of  the  slots  in  the  GH  ontology  have  single  cardinality;  others  have  multiple  cardinality.  Code  in  the  gh5ontology  package  tests 
whether  slots  have  the  expected  cardinality,  and  throw  an  AllowedCIsesCollectionSizeError  if  they  do  not. 

package  ida.sd.gh5ontology; 

import  java. util. Collection; 

import  ida.sd. ontology. CIs; 
import  ida.sd.ontology. Instance; 
import  ida.sd.ontology. Slot; 

jit* 

*  Class  <code>AllowedClsesCollectionSizeError</code>  signals  that  the  GH5  ontology  has  a  slot  that  is  expected  to  allow  instances  of  only  one 

*  class  but  allows  instances  of  multiple  classes.  The  purpose  of  this  class  is  to  encapsulate  and  standardize  the  messages  associated  with  this 

*  error. 

**  i 

public  class  AllowedCIsesCollectionSizeError 
extends  OntologyDefinitionError  { 

jit* 

*  Constructs  an  <code>AllowedClsesCollectionSizeError</code>  for  a  situation  where  the  {@link  Slot}  of  some  {@link  Instance}  was  expected 

*  to  allow  only  one  class  but  allows  multiple. 
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*  @param  inst  The  {@link  Instance}  being  accessed  when  the  error  occurred. 

*  @param  slot  The  {@link  Slot}  being  accessed  when  the  error  occurred. 

*  @param  allowedCIses  The  collection  of  classes  allowed  by  <code>slot</code>. 

**  j 

public  AllowedClsesCollectionSizeError(lnstance  inst,  Slot  slot,  Collection  allowedCIses)  { 
super(inst,  slot,  allowedCIses. size()  +  "  allowed  classes  (expected  1)"); 

} 

jit* 

*  Constructs  an  <code>AllowedClsesCollectionSizeError</code>  for  a  situation  where  the  {@link  Slot}  of  some  {@link  CIs}  was  expected  to 

*  allow  only  one  class  but  allows  multiple. 

*  @param  els  The  {@link  CIs}  being  accessed  when  the  error  occurred. 

*  @param  slot  The  {@link  Slot}  being  accessed  when  the  error  occurred. 

*  @param  allowedCIses  The  collection  of  classes  allowed  by  <code>slot</code>. 

**  j 

public  AllowedClsesCollectionSizeError(Cls  els,  Slot  slot,  Collection  allowedCIses)  { 
super(cls,  slot,  allowedCIses. size()  +  "  allowed  classes  (expected  1)"); 

} 

} 

9.2.  Class  InvalidClsError 

Many  methods  in  the  gh5ontology  package  take  a  value  of  type  Instance  as  a  parameter.  Because  the  ontology  model  is  dynamic,  the 
class  of  an  instance  can’t  be  checked  until  runtime.  Methods  throw  the  InvalidClsError  if  the  class  is  not  what  was  expected. 

package  ida.sd.gh5ontology; 
import  ida.sd.ontology.CIs; 

j ** 

*  The  <code>lnvalidClsError</code>  class  constructs  an  {@link  java. lang. Error}  denoting  that  some  method  was  given  a 

*  {@link  ida.sd.ontology.CIs},  or  an  {@link  ida.sd.ontology.lnstance}  of  a  <code>Cls</code>,  it  didn't  expect. 

*  This  is  a  programming  error  that  must  be  corrected  for  execution  to  succeed. 

**  j 

public  class  InvalidClsError  extends  Error  { 

j ** 

*  Constructs  an  InvalidClsError  with  a  standard  message. 

*  @param  expected  The  {@link  ida.sd.ontology.CIs}  that  was  expected. 

*  @param  received  The  {@link  ida.sd.ontology.CIs}  that  was  received. 

**  j 

public  lnvalidClsError(Cls  expected,  CIs  received)  { 
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super("Expected  "  +  expected.getName()  +  ",  received  "  +  received.getName()); 

} 

} 

9.3.  Class  OntologyDefinitionError 

The  OntologyDefinitionError  class  is  the  superclass  of  all  classes  that  indicate  an  error  in  the  definition  of  the  GH  ontology.  In  other 
words,  these  errors  indicate  a  problem  in  the  GH  ontology  (or  knowledge  base)  as  opposed  to  the  code, 
package  ida.sd.gh5ontology; 

import  ida.sd. ontology. CIs; 
import  ida.sd. ontology. Instance; 
import  ida.sd. ontology. Slot; 

jit* 

*  Class  <code>OntologyDefinitionError</code>  signals  that  the  GH5  ontology  does  not  conform  to  some  expectation. 

**  i 

public  class  OntologyDefinitionError 
extends  Error  { 

I** 

*  Constructs  an  <code>OntologyDefinitionError</code>  based  on  a  message. 

*  @param  message  The  message  that  is  to  be  associated  with  the  error. 

**  j 

public  OntologyDefinitionError(String  message)  { 
super(message); 

} 

jit* 

*  Constructs  an  <code>OntologyDefinitionError</code>  for  a  {@link  Slot}  of  a  given  {@link  Instance}. 

*  @param  inst  The  instance  that  caused  the  error. 

*  @param  slot  The  slot  of  <code>inst</code>  that  caused  the  error. 

*  @param  message  A  description  of  the  error. 

**  j 

public  OntologyDefinitionError(lnstance  inst,  Slot  slot,  String  message)  { 
this(inst.getDirectType(),  slot,  message); 

} 

j ** 

*  Constructs  an  <code>OntologyDefinitionError</code>  for  a  {@link  Slot}  of  a  given  {@link  CIs}. 

*  @param  els  The  class  that  caused  the  error. 

*  @param  slot  The  slot  of  <code>cls</code>  that  caused  the  error. 
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*  @param  message  A  description  of  the  error. 

**  j 

public  OntologyDefinitionError(Cls  els,  Slot  slot,  String  message)  { 
this(cls.getName()  +  +  slot.getName()  +  "  +  message); 

} 

} 

9.4.  Class  TIVError 

Many  own  slot  values  of  GH  ontology  classes  have  a  subclass  of  Type  as  their  value  type.  Class  Type  has  a  template  slot  type-instance- 
value.  Subclasses  of  Type  specialize  the  value  type  of  this  slot,  either  into  a  built-in  type  (integer,  float,  string)  or  another  class  (e.g., 
Numeric-Expression).  If  a  method  finds  that  an  instance  of  Type  has  a  type-instance-value  with  some  value  type  other  than  that  expected,  it 
will  throw  an  instance  of  TIVError. 

package  ida.sd.gh5ontology; 
import  ida.sd.ontology.*; 

I** 

*  Class  <code>TIVError</code>  signals  an  error  in  the  definition  of  a  GH5  ontology  related  specifically  to  a  misuse  of  the 

*  <code>type-instance-value</code>  slot.  The  purpose  of  this  class  is  to  standardize  the  information  associated  with  the  error. 

**  j 

public  class  TIVError 

extends  OntologyDefinitionError  { 

j ** 

*  Constructs  a  <code>TIVError</code>  for  a  situation  where  some  class  was  expected  to  be  the  allowed  class  of  the 

*  <code>type-instance-value</code>  slot,  but  the  <code>type-instance-value</code>  slot  in  question  allows  some  other  class. 

*  @param  inst  The  {@link  Instance}  being  accessed  when  the  error  occurred. 

*  @param  slot  The  {@link  Slot}  being  accessed  when  the  error  occurred. 

*  @param  expected  The  {@link  CIs}  that  was  expected  to  be  allowed. 

*  @param  received  The  {@link  CIs}  that  the  <code>type-instance-value</code>  slot  of  <code>slot</code>  allows. 

**  j 

public  TIVError(lnstance  inst,  Slot  slot,  CIs  expected,  CIs  received)  { 

super(inst,  slot, "  Expected  "  +  expected.getName()  +  ",  received  "  +  received.getName()); 

} 

} 
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